Fix device_class calculatoin for non-root FreeBSD users
libpci uses PCIOCGETCONF for non-privileged access to /dev/pci
and calculates device_class value based on pc_class/pc_subclass
fields expecting the former to be higher 8 bits of the target value. 0f3d0ca73ecedaba180bf4607bb57fb8abe6d405 errorneously swapped
order of class/subclass during calculations.
Daniel Schaefer [Sun, 14 Oct 2018 20:48:57 +0000 (22:48 +0200)]
Enable setpci to target n-th capability of id
Because a capability can exist multiple times with the same id,
there needs to be a way to target a specific one. Instead of
the current behaviour which always targets the first one.
Now you can optionally add `@number` (e.g `@1`) after the width to
choose which one to target.
Masanobu SAITOH [Thu, 4 Oct 2018 08:33:21 +0000 (17:33 +0900)]
Print Root complex related registers on RCEC, too
PCIe spec says root ports and root complex event collectors must implement
root CAP, STAT and CTRL registers, so call cap_express_root() not only for
PCI_EXP_TYPE_ROOT_PORT but also for PCI_EXP_TYPE_ROOT_EC.
Martin Mares [Sun, 12 Aug 2018 09:13:05 +0000 (11:13 +0200)]
Tree: Detect bridges properly
Previously, only PCI_CLASS_BRIDGE_PCI was considered, which excluded
CardBus bridges. We now accept anything of the base class "bridge"
with the proper header type.
Martin Mares [Tue, 26 Jun 2018 10:14:18 +0000 (12:14 +0200)]
Convert other string properties to the generic mechanism
This removes the need of explicit memory management and fixes
PCI_FILL_RESCAN.
To keep backward compatibility, I am keeping the raw pointers
in struct pci_dev, but they point inside the pci_property instead
of separately allocated memory.
Martin Mares [Tue, 26 Jun 2018 10:08:37 +0000 (12:08 +0200)]
Created a generic interface for device properties
Introduction of device tree node properties broke library ABI.
I gave up on creating new symbol versions whenever we add a new
device property, so I introduced a generic property interface
with which new string properties can be added while keeping ABI
compatibility.
return.0 [Mon, 18 Jun 2018 22:00:31 +0000 (17:00 -0500)]
pciutils: Add decoding of vendor specific VPD fields
IBM has defined several VPD fields that are not part of the PCI
spec, but are frequently used on embedded and pluggable pcie
adapters.
Since these fields are "Unknown", they are listed in hex
and less readable.
This patch adds commonly used vendor specific VPD keywords
described in "Table 160. LoPAPR VPD Fields" of the Linux on Power
Architecture Platform Reference (LoPAPR).
Martin Mares [Sun, 27 May 2018 11:49:55 +0000 (13:49 +0200)]
lspci: "virtual" resource regions recognized properly
We wanted to add a "[virtual]" marker to all resources which are
known to the kernel, but not configured in the hardware. That is,
those where the BAR is all zero.
However, the test was never triggered for I/O regions, since their
BAR is never zero: it always has the region type bit set.
lspci: Use spec name for RCRB ((Root Complex Register Block)
Extended Capability ID 0x000a is the RCRB (Root Complex Register Block)
capability. Change the #define and the capability label to match the
terminology used in the specs.
The PCI Code and ID Assignment spec, r1.9, sec 2, defines a "Null
Capability" containing no registers other than the 8-bit Capability ID
(00h) and an 8-bit Next Capability Pointer.
Some devices, e.g., the Intel [8086:2058] implement this Capability.
For capabilities we don't know how to decode, we print the config address,
version, and capability ID:
Capabilities: [220 v1] #19
This doesn't clearly identify the capability ID ("19"), whether it is a
PCI-compatible Capability ID or an Extended Capability ID (although you can
infer this by whether the address is 2 or 3 digits), or the fact that the
ID is printed in hex, which makes it hard to parse this manually.
Add a label ("Capability ID" or "Extended Capability ID") and print a "0x"
prefix so it's clear the value is in hex:
Capabilities: [220 v1] Extended Capability ID 0x19
Viktor Prutyanov [Tue, 20 Mar 2018 19:20:34 +0000 (22:20 +0300)]
lspci: fix printing DeviceName
In commit ef6c9ec3a45992d9e7ef4716d444252baf2013e1 pci_fill_info() calls were moved
and the label field is filled after its output.
Before this patch lspci never prints 'DeviceName'.
Signed-off-by: Viktor Prutyanov <viktor.prutyanov@virtuozzo.com>
Martin Mares [Sat, 17 Mar 2018 15:28:15 +0000 (16:28 +0100)]
Introduced an explicit probe sequence
Previously, the probe order was determined by the order of back-ends.
However, new back-ends must be always added at the end of the list
to maintain ABI compatibility, so they were always probed last.
Martin Mares [Sat, 17 Mar 2018 11:39:00 +0000 (12:39 +0100)]
Adjust prototypes of xmalloc(), xrealloc() and xstrdup()
SylixOS defines its own versions of these functions in its standard
library, which collide with ours. However, their prototypes make
more sense, because they follow the prototypes of the non-x versions
in the C standard, so there is no harm in following them.
PCIe r4.0, sec 6.2.2, classifies errors as Correctable or Uncorrectable.
Uncorrectable includes both Non-Fatal and Fatal errors. Decode the DevSta
"Non-Fatal Error Detected" bit as "NonFatalErr", not "UncorrErr":
Change the "Unsupported" and "UnsuppReq" labels in DevCtl and DevSta to
match the "UnsupReq" used in AER.
The Correctable error category doesn't include Non-Fatal errors, so change
the AER Correctable Error Status "Advisory Non-Fatal Error Status" from
"NonFatalErr" to "AdvNonFatalErr":
Bjorn Helgaas [Fri, 8 Dec 2017 21:24:10 +0000 (15:24 -0600)]
lspci: Decode "VGA 16-bit decode" in bridge control register
Decode the "VGA 16-bit decode" bit in the bridge control register. This
bit was added in the PCI-to-PCI Bridge Arch Spec, r1.2, sec 3.2.5.18.
Note that the bit is only meaningful if the VGA Enable bit or the VGA
Palette Snoop Enable bit is set.
Rudolf Marek [Fri, 29 Dec 2017 20:58:41 +0000 (21:58 +0100)]
pciutils: Add the support for a DOS/DJGPP environment
Here is bit a blast from the past. The flashrom still supports the DOS/DJGPP environment, which requires
pciutils to be compiled with DJGPP. I originally developed this patch in 2010,
and I respun it for latest pciutils.
* Add DJGPP as an OS target
* Stop if endianess macros are not defined
* Introduce new intel_io_lock/unclock function to synchronize
I/O operations.
There is a small issue left that "lspci" and "lspci.exe" are created. The ".exe" variants
are not installed and also not cleaned. No idea if you want to fix that or not.
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Compiled with:
Martin Mares [Fri, 17 Nov 2017 12:58:23 +0000 (13:58 +0100)]
pciutils: change MN VPD keyword to F_TEXT
The PCI spec defines all keyword data fields as ASCII unless
otherwise noted. The MN keyword is not otherwise noted. To make
the MN field human readable in lspci verbose outputs, this patch
changes the MN keyword definition from F_BINARY to F_TEXT.
Imre Vadász [Fri, 14 Jul 2017 21:05:53 +0000 (23:05 +0200)]
fbsd-device: Use PCIOCGETCONF and PCIOCGETBAR when /dev/pci fd is readonly.
This way we can at least fulfill some of the common requests without root
privileges. This allows various applications (for example the google chrome
webbrowser) to successfully probe the list of PCI devices without needing
read-write access to the /dev/pci device file.
Per PCIe spec r3.1, sec 7.8.6, the L0s Exit Latency is only valid when L0s
is supported, and similarly the L1 Exit Latency is only valid when L1 is
supported.
Only decode the L0s and L1 Exit Latencies if they are defined.
For example, on a device that supports L1 but not L0s, the difference in
the "lspci -vv" output looks like this:
lspci: Decode "Slot Implemented" for PCI/PCI-X to PCIe Bridges
The secondary side of a PCI/PCI-X to PCIe Bridge (a "reverse bridge") is a
PCIe Downstream Port and could support a slot just like Root Ports and
Switch Downstream Ports.
Decode "Slot Implemented" for reverse bridges and, if true, the Slot
Capabilities, Control, and Status registers.
For a reverse bridge with no slot, the difference in the "lspci -vv" output
looks like this:
Decode the AER Root Error Command, Root Error Status, and Error Source
Identification registers.
Per PCIe r3.1, sec 7.10, these registers are only available for Root Ports
and Root Complex Event Collectors, so we have to check the Device/Port Type
from the PCIe capability.
The difference in the "lspci -vv" output looks like this (for a Root Port):
Dump the AER Header Log register. This contains the header for the TLP
corresponding to a detected error.
It's probably beyond the scope of lspci to decode the header itself, but
it's interesting to at least show the data as a hint for human readers.
The difference in the "lspci -vv" output looks like this:
projects / thirdparty / pciutils.git / log
