| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Emulated config space contains only few information so it could look like
some valid config space. libpci compose emulated config space either from
struct pci_dev or put some fake information (when struct pci_dev does not
have them).
To prevent showing to user fake/bogus information about PCI devices, show
only information which are directly stored in struct pci_dev when emulated
config space is used.
Do it via setting lspci's header type to invalid value (byte)-1, so lspci
code will handle device as unknown without trying to interpret values
config space. This header type is set only in lspci, not in libpci, so
other libpci applications would see valid config space.
lspci users are probably not interested in fake information provided by
libpci just for purpose to export syntactically valid config space.
Information stored in struct pci_dev are the correct one (or rather what OS
things that is correct).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use pci_fill_info with CLASS_EXT and SUBSYS to fill this information.
lspci in some places reads class from what libpci provider fills in
dev->device_class and in some other places it reads directly from config
space. In dev->device_class is stored class possible different class as in
config space (e.g. if kernel is fixing class because device has bogus
information stored in config space).
With this change is class always read from dev->device_class which reflects
and respects lspci -b option (Bus-centric view). Same applies for subsystem
ids and revision id (note that prog if is part of class).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently PCI domains are printed in ascending order. Devices on each PCI
bus are also printed in ascending order. PCI buses behind PCI-to-PCI
bridges are also printed in ascending order.
But buses of PCI domain are currently printed in descending order because
function new_bus() puts newly created bus at the beginning of linked list.
In most cases PCI domain contains only one (top level) bus, so in most
cases it is not visible this inconsistency.
Multibus PCI domains (where PCI domain contains more independent top level
PCI buses) are available on ARM devices.
This change fixes print order of multibus PCI domains, so also top level
PCI buses are printed in ascending order, like PCI buses behind PCI-to-PCI
bridges.
|
| | |
|
| |
|
|
|
|
| |
The topology tree is now independent of the plain device list
and it can be traversed in both top-to-bottom and bottom-to-top
directions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
make ZLIB=no DNS=no HOST=i386-djgpp-djgpp CROSS_COMPILE=i586-pc-msdosdjgpp- \
PREFIX=/ DESTDIR=$PWD/../libpci-libgetopt \
STRIP="--strip-program=i586-pc-msdosdjgpp-strip -s" install install-lib
If you put to C:\share\pci.ids file, the lspci.exe will also display the human readable output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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):
+ RootCmd: CERptEn- NFERptEn- FERptEn-
+ RootSta: CERcvd- MultCERcvd- UERcvd- MultUERcvd-
+ FirstFatal- NonFatalMsg- FatalMsg- IntMsg 0
+ ErrorSrc: ERR_COR: 0000 ERR_FATAL/NONFATAL: 0000
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
virtio uses vendor-specific capabilities to specify the location of
the virtio register ranges. The specification can be found here:
http://docs.oasis-open.org/virtio/virtio/v1.0/cs01/virtio-v1.0-cs01.html#x1-690004
This patch adds support for decoding these capabilities to lspci.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
| |
|
|
|
|
|
|
| |
CardBus bridges can have capabilities, but the CAP_PTR register is at a
different location. This one has Power Management:
CardBus bridge: O2 Micro, Inc. OZ711SP1 Memory CardBus Controller (rev 01)
+ Capabilities: [a0] Power Management version 2
|
| |
|
|
|
| |
With modutils built upon libkmod, modules.pcimap does not exist
any longer.
|
| | |
|
| | |
|
| |
|
