summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | cxl: Rename caps to be device capsBen Widawsky2022-09-302-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Co-authored-by: Jaxon Haws <jaxon.haws@amd.com> Signed-off-by: Jaxon Haws <jaxon.haws@amd.com>
| * | | cxl: Rework caps to new functionBen Widawsky2022-09-301-9/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will help upcoming caps Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Co-authored-by: Jaxon Haws <jaxon.haws@amd.com> Signed-off-by: Jaxon Haws <jaxon.haws@amd.com>
| * | | cxl: Collect all DVSEC Device fieldsBen Widawsky2022-09-292-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Co-authored-by: Jaxon Haws <jaxon.haws@amd.com> Signed-off-by: Jaxon Haws <jaxon.haws@amd.com>
| * | | cxl: Make id check more explicitBen Widawsky2022-09-291-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently only type 0 DVSEC caps are handled. Moving this check will allow more robust type handling in the future. Should be no functional change. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Signed-off-by: Jaxon Haws <jaxon.haws@amd.com>
| * | | cxl: Rename variable to match other codeBen Widawsky2022-09-291-10/+10
| |/ / | | | | | | | | | | | | | | | | | | | | | The current variable is word sized, and so this makes the CXL code match the rest of the code. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Signed-off-by: Jaxon Haws <jaxon.haws@amd.com>
* | | Merge remote-tracking branch 'pali/lspci-tree-filter'Martin Mares2022-10-301-34/+93
|\ \ \
| * | | lspci: Fix filter support (-s/-d) for subtrees in tree mode (-t)Pali Rohár2022-10-291-34/+93
| |/ /
* | | Maint: Tag releases with my new PGP keyMartin Mares2022-08-101-1/+1
|/ /
* | Avoid adding multiple version tags to the same symbolMartin Mares2022-08-101-4/+8
|/ | | | This is apparently forbidden in most versions of binutils.
* Released as 3.8.0.v3.8.0Martin Mares2022-04-183-5/+5
|
* Filters: Fixed symbol versioningMartin Mares2022-04-181-4/+4
|
* README and ChangeLog for 3.8.0.Martin Mares2022-04-163-4/+42
|
* Document new filter syntax in man pagesMartin Mares2022-04-162-7/+8
|
* Filters now support partially specified classes and also prog-if'sMartin Mares2022-04-163-97/+187
| | | | Rewritten the filter parser, the old code was too twisted to extend.
* pciutils.lsm: metalab.unc.edu is goneMartin Mares2022-04-161-3/+0
|
* Updated pci.ids to today's snapshotMartin Mares2022-04-161-240/+2472
|
* lspci: Fix detection of memory space barPali Rohár2022-04-161-1/+1
| | | | | | | | | | | | | | intel-conf1 backend never show AtomicOpsCap: capabilities despite the fact that is successfuly detects memory bars on device. But other backends show this capability. Error is in device_has_memory_space_bar() function, it expects that ->size member is always filled. But size of the BAR is not available in PCI config space and therefore raw backends cannot retrieve it. Probably intention of the non-zero check was to verify that base address was filled with non-zero size. So either base address is non-zero or length is non-zero. Adjust check.
* lspci: Fix detection of extended capabilitiesPali Rohár2022-04-161-1/+1
| | | | | Bus may report all-ones when trying to access non-existent extended space. Same check is also in lib/caps.c extended space parser.
* lspci: Fix detection of virtual regionsPali Rohár2022-04-161-23/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* lspci: Fix handling of truncated lines for msvcrt.dllPali Rohár2022-04-161-1/+5
| | | | | msvcrt.dll's vsnprintf() implementation does not fill terminating null byte when overflow occurs and buffer size is returned.
* libpci: i386-io-windows.h: Fix error handling for GetProcessImageFileNameW() ↵Pali Rohár2022-04-151-3/+67
| | | | | | | and GetModuleFileNameExW() These functions may require buffer which is larger than MAX_PATH (wide) characters and their error handling is more complicated. Fix it.
* libpci: i386-io-windows.h: Fix MinGW build with pre-4.00 MSVCRT runtime libraryPali Rohár2022-04-151-4/+4
| | | | Like CRTDLL library, pre-4.00 MSVCRT runtime library does not provide I/O port functions.
* libpci: Always call pci_set_name_list_path() in pci_init_name_list_path()Pali Rohár2022-04-151-1/+4
| | | | | | | | | | | If pci_init_name_list_path() does not call pci_set_name_list_path() then a->id_file_name variable is NULL and pci_load_name_list() would crash as it tries to do fopen(NULL, ...). If libpci was configured at compile time to use current executable path for locating pci.ids file and it is not possible to determinate current executable path then call pci_set_name_list_path() with just filename without path (this would fallback to the current working directory).
* libpci: Compile windows i386-ports only for x86 CPUPali Rohár2022-04-151-0/+2
| | | | There are already arm32 and arm64 port of MinGW-w64 toolchain.
* fbsd-device: One more fixMartin Mares2022-04-151-1/+1
| | | | Finishes the incomplete fix from 5c649bdcedfd823670dcbd74e9c38849d068db80.
* Fix lspci: Power Management Control/Status PCI to PCI Bridge Support ExtensionsMikhail Bratchikov2022-04-151-2/+2
|
* README: Mention cfgmgr32 for WindowsPali Rohár2022-04-151-1/+1
|
* README: Update information about WindowsPali Rohár2022-04-151-2/+12
| | | | Basic support for 64-bit systems is there.
* pcilib.man: Include information about win32-cfgmgr32Pali Rohár2022-04-151-0/+10
|
* lspci: Do not access config space when it is emulatedPali Rohár2022-04-153-8/+16
| | | | | | | | | | | | | | | | | | | | | 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).
* libpci: Add windows cfgmgr32 implementationPali Rohár2022-04-157-1/+1731
| | | | | | | | | Access via cfgmgr32.dll library allows to list PCI devices and retrieve their basic properties and system resource configuration. Access is available to all users and should not require special privileges, access tokens, rights or permissions. This cfgmgr32.dll library does not provide access to PCI config space.
* libpci: Implement virtual config space for provides without access to config ↵Pali Rohár2022-04-154-0/+304
| | | | | | | | | | space Add a new pci_dev member no_config_access which signals that there is no access to config space for particular device. Reading operation in this case should return data from emulated virtual config space. For provides there is a new helper function pci_generic_read() which emulates config spaces based on struct pci_dev members.
* lspci: Show information also for devices with unknown header typePali Rohár2022-04-151-27/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* libpci: Define some more PCI_IORESOURCE flags (compatible with ioport.h)Pali Rohár2022-04-151-0/+6
| | | | | These flags define mapping between PCI config space and system resources. So non-sysfs/procfs providers can fill these flags too.
* Tried to fix the fbsd-device back-endMartin Mares2022-04-141-5/+5
| | | | It was left broken by the fill_info reform.
* pciutils: Add decode support for Data Object Exchange Extended CapabilityJonathan Cameron2022-02-263-0/+355
| | | | | | | | | | | | | | | | | | | | | | | PCI Data Object Exchange [1] provides a mailbox interface used as the transport for various protocols defined by PCI-SIG and others. Make the limited information in config space available. Note the Read/Write Mailbox registers themselves are not currently parsed as the usefulness of accessing one dword of a protocol is probably limited. In future, operating systems may provide means to safely query the supported protocols, but those have not yet been defined. Example output: Capabilities: [100 v1] Data Object Exchange DOECap: IntSup+ Interrupt Message Number 001 DOECtl: IntEn+ DOESta: Busy- IntSta- Error- ObjectReady+ [1] PCIe r6.0, sections 6.30 and 7.9.24 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
* lspci: Decode PCIe 6.0 Slot Power Limit valuesPali Rohár2022-02-261-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | When the Slot Power Limit Scale field equals 00b (1.0x) and Slot Power Limit Value exceeds EFh, the following alternative encodings are used: F0h > 239 W and ≤ 250 W Slot Power Limit F1h > 250 W and ≤ 275 W Slot Power Limit F2h > 275 W and ≤ 300 W Slot Power Limit F3h > 300 W and ≤ 325 W Slot Power Limit F4h > 325 W and ≤ 350 W Slot Power Limit F5h > 350 W and ≤ 375 W Slot Power Limit F6h > 375 W and ≤ 400 W Slot Power Limit F7h > 400 W and ≤ 425 W Slot Power Limit F8h > 425 W and ≤ 450 W Slot Power Limit F9h > 450 W and ≤ 475 W Slot Power Limit FAh > 475 W and ≤ 500 W Slot Power Limit FBh > 500 W and ≤ 525 W Slot Power Limit FCh > 525 W and ≤ 550 W Slot Power Limit FDh > 550 W and ≤ 575 W Slot Power Limit FEh > 575 W and ≤ 600 W Slot Power Limit FFh Reserved for Slot Power Limit Values above 600 W Previously only values F0h, F1h and F2h were covered.
* Merge remote-tracking branch 'github/master'Martin Mares2022-02-101-4/+3
|\
| * libpci: i386-io-windows.h: Fix comment about CRTDLLPali Rohár2022-02-101-4/+3
| | | | | | | | | | | | There is no 64-bit version of CRTDLL library. MinGW-w64 provided bogus 64-bit import library for non-existent runtime DLL library, which was recently deleted.
* | lspci: Replace find_driver() via libpci PCI_FILL_DRIVERPali Rohár2022-02-101-40/+16
| | | | | | | | | | And implement this show_kernel() and show_kernel_machine() for all platforms.
* | libpci: sysfs: Implement support for PCI_FILL_DRIVERPali Rohár2022-02-101-0/+14
| | | | | | | | In sysfs is driver name stored as symlink path of "driver" node.
* | libpci: proc: Implement support for PCI_FILL_DRIVERPali Rohár2022-02-101-2/+20
| | | | | | | | File /proc/bus/pci/devices contains optional driver name in the last 18th field.
* | libpci: Define new string property PCI_FILL_DRIVERPali Rohár2022-02-101-0/+1
| | | | | | | | | | | | | | | | | | | | This change extends libpci library and allows providers to fill PCI_FILL_DRIVER via native system APIs. As it is string property there is no need to increase ABI version. Intended usage in application is just: const char *driver = pci_get_string_property(d->dev, PCI_FILL_DRIVER);
* | lspci: Do not show -[00]- bus in tree outputPali Rohár2022-02-101-1/+3
| | | | | | | | | | | | | | Secondary or subordinate bus cannot be zero. Zero value could indicate either invalid secondary bus value or the fact that secondary bus value was not filled or indicates non-compliant PCI-to-PCI bridge. This change makes tree output better readable when bus numbers are not known or not provided.
* | lspci: Build tree based on PCI_FILL_PARENT informationPali Rohár2022-02-102-5/+62
| | | | | | | | | | | | | | | | | | | | | | 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.
* | libpci: sysfs: Implement support for PCI_FILL_PARENTPali Rohár2022-02-101-0/+33
| |
* | libpci: Add new option PCI_FILL_PARENTPali Rohár2022-02-101-0/+2
| | | | | | | | | | This change extends libpci and allows providers to fill parent pci_dev. This is useful to retrieve topology as it is reported by the system itself.
* | lspci: Retrieve prog if, subsystem ids and revision id via libpciPali Rohár2022-02-103-53/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* | libpci: sysfs: Implement CLASS_EXT and SUBSYS supportPali Rohár2022-02-101-2/+32
| | | | | | | | In sysfs there are optional nodes with this information.
* | libpci: generic: Implement SUBSYS also for PCI_HEADER_TYPE_BRIDGEPali Rohár2022-02-101-0/+9
| | | | | | | | | | Subsystem ids for PCI Bridges are stored in extended capability PCI_CAP_ID_SSVID.
View Lorry Controller Status