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).
Martin Mares [Sun, 2 Nov 2014 11:11:05 +0000 (12:11 +0100)]
Backward ABI compatibility for new filters and pci_fill_info
This is tricky, because we have to translate between old and new
format of struct pci_filter. At least, I added several RFU fields
so this hopefully won't have to happen again soon.
Matthew Wilcox [Tue, 30 Sep 2014 18:02:52 +0000 (14:02 -0400)]
lspci: Add ability to filter by class code
Extend the 'filter by device ID' functionality to allow optional
specification of a device ID. For example, to list all USB controllers
in the system made by Intel, specify:
lspci -d 8086::0c03
Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
Martin Mares [Sun, 2 Nov 2014 10:23:20 +0000 (11:23 +0100)]
Clean up man pages
We do not call .IX as it's not defined in mandoc.
Ellipsis at the end of line is protected by \&.
Inspired by Debian patches for the following bugs:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674708
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675087
Martin Mares [Sat, 1 Nov 2014 17:38:08 +0000 (18:38 +0100)]
Rewritten support for UDEV's HWDB
HWDB is now handled in a way very similar to the DNS resolver.
The interface lives in a separate source file (lib/names-hwdb.c),
results of lookups are cached. Use of HWDB can be disabled either
by passing PCI_LOOKUP_NO_HWDB or by setting the hwdb.disabled
configuration parameter.
Also, there should be no more leaks of libudev's structures.
Tom Gundersen [Mon, 30 Dec 2013 18:59:53 +0000 (19:59 +0100)]
libpci: pci_id_lookup - add udev/hwdb support
This lets you select hwdb support at compile time.
hwdb is an efficient hardware database shipped with recent versions of udev. It contains
among other sources pci.ids so querying hwdb rather than reading pci.ids directly should give
the same result.
Ideally Linux distros using udev could stop shipping pci.ids, but use hwdb as the only source
of this information, which this patch allows.
projects / thirdparty / pciutils.git / log
