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