History log of /pciutils/lspci.c (Results 1 – 25 of 177)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v3.14.0, v3.13.0
# 49efa87f 30-May-2024 Kobayashi Daisuke <[email protected]>

Add display function for cxl1.1 device link status information. (#183)

* Add display function for cxl1.1 device link status information.

* Modifications according to comments. Adding a descriptio

Add display function for cxl1.1 device link status information. (#183)

* Add display function for cxl1.1 device link status information.

* Modifications according to comments. Adding a description, Fix odd indent, and remove unnecessary statement.

show more ...


Revision tags: v3.12.0, v3.11.1, v3.11.0
# 0ce6ff4a 27-Dec-2023 Nikita Proshkin <[email protected]>

lspci: Fix unsynchronized caches in lspci struct device and pci struct pci_dev

lspci initializes both caches for the device to the same memory block in
its scan_device function. Latter calls to conf

lspci: Fix unsynchronized caches in lspci struct device and pci struct pci_dev

lspci initializes both caches for the device to the same memory block in
its scan_device function. Latter calls to config_fetch function will
realloc cache in struct device, but not in struct pci_dev leading to
the invalid pointer in the latter. pci_dev cache is used by pci_read_*
functions, what will lead to a possible use-after-free situations.

Example:

With patch:

show more ...


# 61829219 18-Jun-2023 Martin Mares <[email protected]>

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


Revision tags: v3.10.0
# 6e766463 01-May-2023 Martin Mares <[email protected]>

lspci: Allow longer name strings


Revision tags: v3.9.0, v3.8.0
# 7f96c3fe 05-Mar-2022 Pali Rohár <[email protected]>

lspci: Fix detection of virtual regions

There are many issues with detection of virtual regions.

1. Variable for detecting virtual region is global and if one BAR is marked
as virtual then all r

lspci: Fix detection of virtual regions

There are many issues with detection of virtual regions.

1. Variable for detecting virtual region is global and if one BAR is marked
as virtual then all remaining BARs are treated as virtual too as this
variable is not reset at next loop iteration.

2. Lower address is read from flg variable which on backends without config
space is initialized from PCI flags, not from base address.

3. Code mixes at many places PCI flags, resource flags, PCI addresses and
resource addresses. Some backends reports PCI flags in PCI addresses,
some not.

Cleanup mess of ->base_addr, ->flags and PCI_BASE_ADDRESS. If backend
provides ->flags value (test via PCI_FILL_IO_FLAGS) then use it instead of
reading flags from pci config space.

Fix reading of PCI hw_lower and hw_upper addresses. If PCI_BASE_ADDRESS
reports different type than what is stored in base_addr then completely
ignore hw_lower and hw_upper values. It means that backend either provide
fiction information or provide resources in different order as they are
stored in hardware. In any case values from HW cannot be used as they do
not match values reported by backend.

And in the last case, make virtual variable local to the current BAR
processing and do not increment loop variable i when 64-bit MEM type is
detected via data from config space. It could miss some virtual resource
reported by the backend.

This change fixes displaying resources of PCI devices which have some
unset/unused BARs in the middle and OS reports virtual regions and
remaining regions without holes. E.g. HW BARs 0, 2, 5 are used and OS
reports base_addr 0, 1, 2, 3.

show more ...


# 832b07a8 28-Dec-2021 Pali Rohár <[email protected]>

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


# 72cabfbb 27-Feb-2022 Pali Rohár <[email protected]>

lspci: Show information also for devices with unknown header type

lspci sees header type with 0x7f value in case config space is not
accessible. It may be because of permission issues or missing bac

lspci: Show information also for devices with unknown header type

lspci sees header type with 0x7f value in case config space is not
accessible. It may be because of permission issues or missing backend
(e.g. on Windows) or because device itself does not respond to config
cycles and config space is inaccessible.

Inaccessible config space is common scenario for switchable PCIe GPU
cards. Some Nvidia and also some AMD cards when sleep then lspci sees
all-ones in their config space. But kernel has registered those cards and
some of their properties are cached ans available via sysfs or procfs (from
time when card was awake).

Currently lspci shows error message "Unknown header type 7f" and does not
parse any value neither from config space nor from sysfs backend.

So try to show at least information which kernel provided into libpci
struct pci_dev.

Set unknown values to zeros (instead of all-ones which are returned from
config space) and add a new function show_htype_unknown() for showing
additional information in case header type is unknown.

This change will also help new windows backend which has only emulated
config space and therefore valid data only in struct pci_dev.

show more ...


# 67954c8b 28-Dec-2021 Pali Rohár <[email protected]>

lspci: Build tree based on PCI_FILL_PARENT information

Topology reported by system (libpci provider) may be different from
topology built based on primary/secondary/subordinate numbers from PCI
brid

lspci: Build tree based on PCI_FILL_PARENT information

Topology reported by system (libpci provider) may be different from
topology built based on primary/secondary/subordinate numbers from PCI
bridges by lspci.

This happens for example when some non-compliant PCI-to-PCI bridge
with Type 0 header (e.g. Marvell one) is available in the system.

So add additional edges reported by libpci when building tree in lspci.

show more ...


# fb570ee3 20-Dec-2021 Pali Rohár <[email protected]>

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


# ccf68033 20-Nov-2021 Pali Rohár <[email protected]>

lspci: Use PCI_FILL_BRIDGE_BASES to detect if range behind bridge is disabled or unsupported

Show resources behind bridge as reported by PCI_FILL_BRIDGE_BASES.

I/O or Prefetchable memory behind bri

lspci: Use PCI_FILL_BRIDGE_BASES to detect if range behind bridge is disabled or unsupported

Show resources behind bridge as reported by PCI_FILL_BRIDGE_BASES.

I/O or Prefetchable memory behind bridge is unsupported by bridge if both
base and limit bridge registers are read-only and returns zero. So if base
and limit registers returns zero (which is valid enabled range) and kernel
reports that particular resource is disabled it means that resource is
unsupported. Both I/O or Prefetchable memory resources are only optional.

show more ...


# 3b26eaa8 20-Nov-2021 Pali Rohár <[email protected]>

lspci: Simplify printing range in show_range()

Use just one printf() call with width format argument based on number of bits.


# 66a85e51 18-Oct-2021 Pali Rohár <[email protected]>

lspci: Show 16/32/64 bit width for address ranges behind bridge

Type of address range is encoded in lower bits.


Revision tags: v3.7.0
# a5065438 28-Feb-2020 Alex Xu (Hello71) <[email protected]>

lspci: Print IOMMU groups with -v


Revision tags: v3.6.4, v3.6.3
# cb94f26e 22-Jan-2020 Martin Mares <[email protected]>

Cleaned up dumping of expansion ROM regions

"[virtual]" and "[enhanced]" are now printed after the base address
along with other flags.


# bf72d3e9 22-Jan-2020 Martin Mares <[email protected]>

Cleaned up dumping of I/O and memory regions

Originally, I wanted to fix a bug, which caused 64-bit addresses
with their lower 32 bits zero to be reported as virtual regions.
However, it turned out

Cleaned up dumping of I/O and memory regions

Originally, I wanted to fix a bug, which caused 64-bit addresses
with their lower 32 bits zero to be reported as virtual regions.
However, it turned out that the whole function is quite messy,
so I rewrote it.

Also, we now print "[virtual]" and "[enhanced]" after the base address
along other modifiers.

show more ...


# e6b0b6e1 19-Jun-2019 Kelsey Skunberg <[email protected]>

lspci: Change output for bridge with empty range to "[disabled]"

Change output displayed for memory behind bridge when the range is
empty to be consistent between each verbosity level. Replace "None

lspci: Change output for bridge with empty range to "[disabled]"

Change output displayed for memory behind bridge when the range is
empty to be consistent between each verbosity level. Replace "None" and
"[empty]" with "[disabled]". Old and new output examples listed below
for each verbosity level.

Show_range() is not called unless verbose == true. No output given
unless a verbose argument is provided.

OLD output for -v and -vv which uses "None" and -vvv uses "[empty]":

Memory behind bridge: None # lspci -v
Memory behind bridge: None # lspci -vv
Memory behind bridge: 0000e000-0000efff [empty] # lspci -vvv

NEW output for -v, -vv, and -vvv to use "[disabled]":

Memory behind bridge: [disabled] # lspci -v
Memory behind bridge: [disabled] # lspci -vv
Memory behind bridge: 0000e000-0000efff [disabled] # lspci -vvv

Advantage is consistent output regardless of verbosity level chosen and
to simplify the code.

Signed-off-by: Kelsey Skunberg <[email protected]>

show more ...


# 25f2e4db 19-Jun-2019 Kelsey Skunberg <[email protected]>

lspci: Remove unnecessary !verbose check in show_range()

Remove 'if (!verbose)' code in show_range() due to not being called.
show_range() will only be called when verbose is true. Additional call
t

lspci: Remove unnecessary !verbose check in show_range()

Remove 'if (!verbose)' code in show_range() due to not being called.
show_range() will only be called when verbose is true. Additional call
to check for verbosity within show_range() is dead code.

!verbose was used so nothing would print if the range behind a bridge
had a base > limit and verbose == false. Since show_range() will not be
called when verbose == false, not printing bridge information is
still accomplished.

Signed-off-by: Kelsey Skunberg <[email protected]>

show more ...


# c5751fb0 19-Jun-2019 Kelsey Skunberg <[email protected]>

lspci: Include -vvv option in help

Include -vvv in help message.

Signed-off-by: Kelsey Skunberg <[email protected]>


# 888ddf0e 18-Sep-2018 Gera Kazakov <[email protected]>

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


Revision tags: v3.6.2
# ce22dfec 12-Aug-2018 Martin Mares <[email protected]>

Topology now works in combination with filters

If bus topology is needed, we scan all devices regardless of filters,
and apply the filters later when showing devices.

Also, we forbid several imposs

Topology now works in combination with filters

If bus topology is needed, we scan all devices regardless of filters,
and apply the filters later when showing devices.

Also, we forbid several impossible combinations of options: tree mode
with filters, bus mapping mode with anything requiring topology.

show more ...


# 62e78fa6 10-Aug-2018 Martin Mares <[email protected]>

Added an option for displaying bus paths

Originally implemented by Matthew Wilcox as a stand-alone feature.
I modified it to make use of bus topology calculated by ls-tree.c.


Revision tags: v3.6.1, v3.6.0
# c02d903c 26-Jun-2018 Martin Mares <[email protected]>

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

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.

show more ...


# 6d701ce3 15-May-2018 Oliver O'Halloran <[email protected]>

Add device-tree node path to the verbose output

Adds the path of the device-tree node of a PCI device to the lspci -v
output, like so:

0021:00:00.0 PCI bridge: IBM Device 03dc (prog-if 00 [Normal d

Add device-tree node path to the verbose output

Adds the path of the device-tree node of a PCI device to the lspci -v
output, like so:

0021:00:00.0 PCI bridge: IBM Device 03dc (prog-if 00 [Normal decode])
DT Node: /sys/firmware/devicetree/base/pciex@3fffe41100000/pci@0

This is added as a generic property to struct pci_device and populated
by the sysfs backend. Other platforms may find it useful though.

Signed-off-by: Oliver O'Halloran <[email protected]>

show more ...


# 4cd087d8 27-May-2018 Martin Mares <[email protected]>

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 t

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.

Now, we test only the address part of the BAR.

show more ...


# 2a39bc9e 20-Mar-2018 Viktor Prutyanov <[email protected]>

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 print

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

show more ...


12345678