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:
Keith Busch [Thu, 17 Mar 2016 19:19:17 +0000 (13:19 -0600)]
pciutils: Add support for 32-bit PCI domains
This adds support for new host bridges that may create PCI domain number
values requiring more than 16 bits. The new domain 32-bit integer is
signed to allow -1 for "any", and is sufficient as the domain number
will never require the full 32-bits.
The domain field is appended at the end of struct pci_dev, and the
current location of the 16-bit domain remains for compatibility. The
domain number is truncated and copied into the legacy domain location
so existing applications linking to the library will continue to work
without modification. We accept that these applications may not work
correctly on machines with host bridges exporting 32-bit domains.
In order to force new programs to link to the new ABI, the pci_init
function call is versioned in this commit.
Signed-off-by: Keith Busch <keith.busch@intel.com>
Sean O. Stalley [Fri, 12 Feb 2016 00:52:25 +0000 (16:52 -0800)]
Add support for enhanced allocation regions
Append [enhanced] to Regions that contain the BEI flag in sysfs.
To do this, we need to add the resource flags to the pci_dev struct.
This struct is passed through the libpci API, so we increment the API version number.
Don't truncate least significant bits of the region size.
ex: a 2000 byte region should display [size=2000] instead of [size=1K]
Signed-off-by: Sean O. Stalley <sean.stalley@intel.com>
Yong, Jonathan [Tue, 10 May 2016 03:15:55 +0000 (03:15 +0000)]
lspci: Decode Precision Time Measurement capabiltity
Section 7.32 Precision Time Management (or Measurement) from the
PCI Express Base 3.1 specification is an optional Extended Capability
for discovering and controlling the distribution of a PTM Hierarchy.
Signed-off-by: Yong, Jonathan <jonathan.yong@intel.com>
Bjorn Helgaas [Thu, 10 Dec 2015 19:50:01 +0000 (13:50 -0600)]
lspci: Decode DevCap SlotPowerLimit for all components with Upstream Ports
The SlotPowerLimit in the Slot Capability indicates how much power the slot
can supply to a downstream device. A Root Port or Switch Downstream Port
communicates the limit via a Set_Slot_Power_Limit Message on the link. The
component on the other end of the link copies the limit from the message to
the Captured Slot Power Limit in its Device Capability [see PCIe r3.0, sec
2.2.8.5].
The Captured SlotPowerLimit is relevant for all devices on the downstream
end of a Link. This includes Endpoints and Bridges as well as
Switch Upstream Ports.
Decode the DevCap Captured SlotPowerLimit for Endpoints and Bridges as well
as Switch Upstream Ports.
Martin Mares [Mon, 14 Sep 2015 15:43:04 +0000 (17:43 +0200)]
Sysfs: Read failures of optional attributes are not fatal
Ameya Palande reported that with some kernels, reads of such
attributes fail on some hardware. He suggested to ignore read
failures completely, but I decided to turn the errors into
warnings in such cases. At least, the user will know that something
fishy is going on.
Martin Mares [Mon, 14 Sep 2015 15:00:28 +0000 (17:00 +0200)]
NUMA node scanning is now done in an ABI-compatible way
The numa_node field was moved to the end of the public part of
struct pci_dev. As usually, it has to be requested using the
PCI_FILL_NUMA_NODE and pci_fill_info() is versioned.
Matthew Wilcox [Wed, 22 Apr 2015 20:27:21 +0000 (16:27 -0400)]
Report NUMA node in lspci -v
In multi-socket systems, it's useful to see which node a particular
PCI device belongs to. Linux provides this information through sysfs,
but some users don't like poking through sysfs themselves to find it,
and it's pretty straightforward to report it in lspci.
I should note that when there is no NUMA node for a particular device,
Linux reports -1. I've chosen to continue that convention in pciutils,
and simply omit the information if the device does not belong to a NUMA
node (eg on single-socket systems, or devices which are not preferentially
attached to a particular node, like Nehalem-based systems).
projects / pciutils.git / log