libpci: Add separate file for bit manipulation functions

Move several macros from lspci and add some more for operations with
bit masks.

Reviewed-by: Sergei Miroshnichenko <[email protected]

libpci: Add separate file for bit manipulation functions

Move several macros from lspci and add some more for operations with
bit masks.

Reviewed-by: Sergei Miroshnichenko <[email protected]>
Signed-off-by: Nikita Proshkin <[email protected]>

show more ...

Update license comments and added SPDX license identifiers

Previously, the only information about the specific version of GPL
was present in the README and individual source files mentioned only
GPL

Update license comments and added SPDX license identifiers

Previously, the only information about the specific version of GPL
was present in the README and individual source files mentioned only
GPL alone.

Let us update all copyright comments to explicitly say "GPL v2+"
and also include the machine readable SPDX license identifier.

show more ...

ls-tree: Print PCI domains in ascending order

ls-tree: Rename struct bridge member next to prev

It refers to the previous value in linked-list, not to the next.

lspci: Do not access config space when it is emulated

Emulated config space contains only few information so it could look like
some valid config space. libpci compose emulated config space either f

lspci: Do not access config space when it is emulated

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).

show more ...

lspci: Retrieve prog if, subsystem ids and revision id via libpci

Use pci_fill_info with CLASS_EXT and SUBSYS to fill this information.

lspci in some places reads class from what libpci provider fi

lspci: Retrieve prog if, subsystem ids and revision id via libpci

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).

show more ...

lspci: Print buses of multibus PCI domain in ascending order

Currently PCI domains are printed in ascending order. Devices on each PCI
bus are also printed in ascending order. PCI buses behind PCI-t

lspci: Print buses of multibus PCI domain in ascending order

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.

show more ...

lspci: Allow -s with -t to show a subtree

Generalized topology computation in ls-tree.c

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.

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 o

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 <[email protected]>

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.

show more ...

lspci: Decode AER Root Error Command, Root Error Status, Error Source

Decode the AER Root Error Command, Root Error Status, and Error Source
Identification registers.

Per PCIe r3.1, sec 7.10, these

lspci: Decode AER Root Error Command, Root Error Status, Error Source

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 <[email protected]>

show more ...

Add virtio vendor capability support

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

Add virtio vendor capability support

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 <[email protected]>

show more ...

lspci: Display CardBus bridge capabilities

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.

lspci: Display CardBus bridge capabilities

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

show more ...

On newer Linux systems, use libkmod to look up kernel modules

With modutils built upon libkmod, modules.pcimap does not exist
any longer.

Updated (c) years.

Added helper macros BITS and TABLE

Split lspci to multiple source files.