Driver & firmware fundamentals

Detected, bound, operational: three different facts

Understand PCI/USB enumeration, driver probing and runtime binding before interpreting a driver recommendation.

Enumeration only identifies a bus observation

A numeric PCI or USB pair is evidence that an identifier was reported. It does not reveal every board revision, cable, monitor, radio antenna or device power state. Treat a human-readable name in a pasted report as a reported label. The Explorer checks a curated family against source evidence and preserves uncertainty when an identifier is shared.

lspci -nnk
lsusb

A match is followed by a probe

An upstream ID table is a candidate relationship. The installed kernel must include the driver, configuration must permit it, and its probe must succeed. Firmware loading, platform dependencies or an intentional override may change what binds. A module present on disk or listed by lspci is not the same observation as Kernel driver in use.

Read the actual binding

For a PCI endpoint, the sysfs driver link records a binding in that local system. Use the PCI domain, bus, device and function from your own output. A missing line in a shortened report remains unreported; an explicit unclaimed state is stronger evidence. A vfio-pci binding on a host can be intentional passthrough rather than a broken native driver.

readlink /sys/bus/pci/devices/BDF/driver

References

Source review records a checked implementation or document, not a reproduced hardware test. Version-specific tables do not establish a minimum kernel or guaranteed operation.

Use the local identification tool