| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Extend existing .in resource template file and generate resource objects
also for lspci.exe and setpci.exe executables.
|
|
Lot of non-x86 platforms also support Intel Type 1 mechanism. x86 IO ports
CF8 and CFC are on these platforms mapped into standard memory space.
Address mapping itself is platform or board specific and there is no
default value.
Lot of ARM boards with multiple PCIe controllers are multi-domain and each
PCI domain has its own CF8/CFC (address/data) registers mapped into memory
space.
Add new mmio-conf1 backend which access CF8/CFC ports via MMIO and define
new config option mmio-conf1.addrs which specify list of address/data
register pairs in memory space for each PCI domain. Format of this option
is: 0xaddr1/0xdata1,0xaddr2/0xdata2,...
|
|
|
|
Function pci_generic_scan() scans PCI domain 0. This new function
pci_generic_scan_domain() scans specified PCI domain number.
|
|
Add Global Persistent Flush DVSEC decoding for CXL device according to
DVSEC Revision ID 0.
Decode GPF Phase 2 Duration and GPF Phase 2 Power.
Signed-off-by: Jaxon Haws <jaxon.haws@amd.com>
|
|
Fix decoding of register blocks by introducing offset to position
calculation (8.1.9 of CXL 3.0 spec) and removed unused defines for
Register Locator DVSEC.
Signed-off-by: Jaxon Haws <jaxon.haws@amd.com>
|
|
Show error message from intel_setup_io() function into debug area instead
of error area. This is what other backends do as intel_setup_io() is called
during quite detect phase, which may fail.
Also show human readable failure instead of magic code number.
|
|
|
|
Generate rc file from in template and fill DLL name and DLL version from
Makefile.
It looks like that the only possible way via GNU tools to specify version
information for DLL library is via text rc file compiled as COFF object
file via GNU windres and linked into the final DLL library via GNU ld.
|
|
Windows version of GNU LD has bugs which cause that linker would translate
this unknown unversioned symbols to some random version.
So change pci_fill_info() to pci_fill_info_v38() in lib/filter.c to ensure
that last version of this function would be used also by Windows version of
GNU LD linker.
Before this change GNU LD translated this function call to symbol
_pci_fill_info@LIBPCI_3.0. After this change GNU LD translate it to
_pci_fill_info@LIBPCI_3.8.
|
|
libpci3.dll
PE/COFF format, used by DLL libraries, does not support version symbols
like ELF format. Recommendation from Microsoft for DLL symbol versioning is
to use DLL API sets. But DLL API sets scheme requires for every API change
to generated a new slim forwarding DLL library, which is unsuitable for
distribution which wants just one DLL library with all version symbols.
So instead of Microsoft recommended scheme for DLL versioning, use new
different versioning scheme: Symbol is composed by function name, at (@)
character and version string (version is same as for ELF targets). Symbol
name without version information is added only into the DLL DEF file as
alias to symbol with higest version. So linker at application link time
resolves "unversioned" symbol to the versioned one via this alias and puts
"versioned" symbol into final executable. This works fine if GNU LD is
linking application via import library libpci3.dll.a generated from that
DLL DEF file libpci3.def. But does not work when linking directly to the
DLL library because library itself does not contain aliases. Note that GNU
LD does not support linking to DEF file (it is required to first generated
import library from DEF file).
Note that older GNU LD versions have bug which cause generation of
corrupted DLL files if some symbol contains dot (.) character. Hopefully
this bug was fixed in GNU LD 2.21.
At the end application lspci.exe requires library libpci3.dll with symbols
pci_alloc@LIBPCI_3.0, pci_init@LIBPCI_3.5, pci_fill_info@LIBPCI_3.8 and
therefore libpci3.dll stays backward compatible with future changes.
PE/COFF executables can reference symbols either via name or via its
ordinal number. Because DLL DEF files are generated from libpci version
script and generator ver2def.pl preserves order of symbols, it means that
ordinal numbers stay backward compatible unless order of lines in version
script is changed.
WARNINGS:
GCC an GNU LD for Windows target have some bugs which cause that
-fvisibility=hidden switch and __attribute__((visibility("default"))) does
not work. Seems that they are broken and ignored when building DLL library.
So instead use -Wl,--exclude-all-symbols switch with explicit DLL DEF file
for building DLL library, which seems to work. This switch is supported
since GNU LD 2.21.
GNU LD has also another bug which results in broken DLL library if input
DLL DEF file which describes symbols for exports, contains also symbol
aliases via == operator.
So do not specify symbol aliases in input DLL DEF file for building DLL
library. Instead construct separate DLL DEF file for building libpci3.dll
without symbol aliases and separate DLL DEF file libpci3.def with symbol
aliases for building import library libpci3.dll.a suitable for linking into
target applications. Note that operator == for symbol aliases is supported
since GNU dlltool 2.21.
Generate those two DLL DEF files via new script ver2def.pl from libpci.ver
version script. So exported functions and version symbols would be defined
only at one place in file libpci.ver.
Note that GNU LD for Windows targets has also broken support for version
scripts, it exports nonsense data and completely ignores version
information. So always use only DLL DEF files generated by ver2def.pl
script and never pass original version script to GNU LD.
Due to another bugs in GNU dlltool, ordinals for aliased symbols from DLL
DEF file are calculated incorrectly when building import library. So
calculate ordinals manually in ver2def.pl script and explicitly put then
into generated libpci3.def DLL DEF file for every symbol, including
aliases.
And because aliases are stored only in libpci3.def file (and in import
library libpci3.dll.a generated from that DEF file) and not in DLL library
libpci3.dll itself, it is required to link all libpci applications via
import library and not directly to libpci3.dll. This is limitation of
PE/COFF format used by DLL libraries.
So for building Windows DLL library libpci3.dll is needed to use GNU
binutils 2.21 or new.
|
|
|
|
|
|
Some standard registers are available only on device with header type 0,
some only on header type 1, some other only on header type 2 and some on
header type 0 and 1. Add definitions which registers are available on which
header type and add check to access only available registers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- We now pass capability length and revision to functions
instead of reading them from config space again and again.
- Centralize fetching of the capability.
- Add checks for overrunning capability length.
- Avoid out-of-bounds reads from the array of register names.
- Sort capability list by ID.
|
|
|
|
|
|
|
|
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
Signed-off-by: Jaxon Haws <jaxon.haws@amd.com>
|
|
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>
|
|
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>
---
Add Viral Enable (Jonathan)
Add missing tab (Jonathan)
Add Alt Mem base/limit (Jonathan)
|
|
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>
---
Fix ranges (Pali): https://github.com/pciutils/pciutils/pull/59#discussion_r806335631
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The hurdish methods only implement the region and base information, the
rest should be taken from the generic method.
|
|
|
|
This is apparently forbidden in most versions of binutils.
|
|
GCC header file <x86intrin.h> defines static inline function __readeflags()
which calls correct __builtin_ia32_readeflags_XX() builtin.
Header file <x86intrin.h> is included by MinGW-w64's <intrin.h> header file
in new versions of MinGW-w64 and <intrin.h> may be included transitionally
by some other header files automatically.
Defining __readeflags() as both macro and static inline function cause
compile errors.
Fix this compile error by not defining __readeflags() macro and instead
include GCC header file <x86intrin.h>.
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
'which' is not required by POSIX and is an external command which may not be
available, and 'command -v' does the job just fine.
Debian and Gentoo at least are both making efforts to drop which from
their base system package list.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
Use new variable $(PCIIMPLIB) for storing name of the libpci import library
for linking with shared library $(PCILIB).
This would allow compilation of lspci and setpci applications on systems
where linking needs to be done with import library.
|
|
This would simplify usage of ABI_VERSION variable for platforms which do
not use leading dot in file names.
|
|
Move Darwin and Linux/ELF platform link switches to new PCILIB_LDFLAGS
variable.
|
|
When IDSDIR is empty then current lspci/setpci directory is assumed.
So install PCI_IDS into SBINDIR in this case.
|
|
|
|
|
|
NT SysDbg interface allow access to the PCI config space. Only devices on
the first domain are available and only first 256 bytes of the PCI config
space can be accessed. Compared to intel-conf1 access, this API is race
free as NT kernel serialize access to PCI I/O ports. This NT SysDbg API is
used by the !pci command of 32-bit WinDbg kernel debugger for displaying
PCI config space. Debug privilege is required to use this NT interface.
|
|
|
|
|
|
|
|
|
|
Rewritten the filter parser, the old code was too twisted to extend.
|
|
|
|
|
|
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.
|
|
Bus may report all-ones when trying to access non-existent extended space.
Same check is also in lib/caps.c extended space parser.
|
|
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.
|
|
msvcrt.dll's vsnprintf() implementation does not fill terminating null byte
when overflow occurs and buffer size is returned.
|
|
and GetModuleFileNameExW()
These functions may require buffer which is larger than MAX_PATH (wide)
characters and their error handling is more complicated. Fix it.
|
|
Like CRTDLL library, pre-4.00 MSVCRT runtime library does not provide I/O port functions.
|
|
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).
|
|
There are already arm32 and arm64 port of MinGW-w64 toolchain.
|
|
Finishes the incomplete fix from 5c649bdcedfd823670dcbd74e9c38849d068db80.
|
|
|
|
|
|
Basic support for 64-bit systems is there.
|
|
|
|
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).
|
|
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.
|
|
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 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.
|
|
These flags define mapping between PCI config space and system resources.
So non-sysfs/procfs providers can fill these flags too.
|
|
It was left broken by the fill_info reform.
|
|
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>
|
|
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.
|
|
|
|
And implement this show_kernel() and show_kernel_machine() for all
platforms.
|
|
In sysfs is driver name stored as symlink path of "driver" node.
|
|
File /proc/bus/pci/devices contains optional driver name in the last 18th field.
|
|
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);
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
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).
|
|
In sysfs there are optional nodes with this information.
|
|
Subsystem ids for PCI Bridges are stored in extended capability
PCI_CAP_ID_SSVID.
|
|
PCI_FILL_SUBSYS is implemented only for PCI_HEADER_TYPE_NORMAL and
PCI_HEADER_TYPE_CARDBUS like in lspci.
|
|
This change extends libpci library and allows providers to fill these
informations (Programming interface, Revision id and Subsystem ids) via
native system APIs, which sometimes may differs from what is stored in PCI
config space.
Programming interface is part of 24-bit Device Class number but apparently
libpci exports only high 16-bit of this number via device_class member.
|
|
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.
|
|
Extend libpci API and ABI to fill bridge resources from sysfs.
|
|
Use just one printf() call with width format argument based on number of bits.
|
|
Type of address range is encoded in lower bits.
|
|
|
|
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.
|
|
Windows CRTDLL and MSVCRT runtime system libraries do not support %llu
format string in printf. They support only %I64u format string. Fix this
problem by providing PCI_U64_FMT_U macro in the same way as existing
PCI_U64_FMT_X macro (for %llx).
For C99 systems this PCI_U64_FMT_U macro is defined to C99 PRIu64 constant.
This change fixes printing unsigned decimal 64-bit numbers by lspci on
Window systems independently of used compiler (MinGW or MSVC).
|
|
pciutils already provides and uses u64 type together with PCI_U64_FMT_X
format macro for printing hex value of this type. So use u64 and
PCI_U64_FMT_X also on other few remaining places.
This change fixes printing hexadecimal 64-bit numbers by lspci on Window
systems independently of used compiler (MinGW or MSVC).
|
|
In more files is <unistd.h> header file included without any usage.
MSVC does not provide this header file so remove this useless usage of
<unistd.h> to allow compilation under MSVC.
|
|
According to Win32 API guidelines applications should include <windows.h>
instead of <windef.h>. This change fixes compilation under MSVC as MSVC
<windef.h> header file expects that some other Win32 header files from
<window.h> are already included.
|
|
CRTDLL, MSVCRT and UCRT runtimes provides strncasecmp()-like functionality
in _strnicmp() function. As opposite of strcasecmp() for which there are
_stricmp() and _strcmpi() variants, for strncasecmp() there is only
_strnicmp() function.
Without this change linking final setpci.exe executable undef MSVC fails.
|
|
snprintf() macro is not endian specific and therefore should be declared
outside of the endian section.
This also fixes snprintf() function for new MinGW-w64 toolchains where
snprintf() is defined as wrapper around _snprintf() which do not return
negative value on overflow. libpci would call MinGW-w64 patched snprintf()
function and not broken system function _snprintf().
|
|
MSVC prior version 19.00 do not have vsnprintf() function, only
_vsnprintf().
|
|
On Linux, lspci is useful even for ordinary users, although only
a subset of features is available.
|
|
|
|
Previously, we kept track of which fields were already filled, which
was quite brittle.
Now we keep only the set of already known fields in struct pci_dev.
We check if the current field is needed against this information.
Not only this simplifies the whole thing, but it also enables future
back-ends to call pci_fill_info() recursively as needed.
|
|
Cross-compilers often provide only "gcc" and not "cc".
So let's try "cc" when building natively and "gcc" when cross-compiling.
|
|
Do not report PCIe link downgrades for downstream ports.
Changed wording so that "overdriven" is reported instead of
"strange" for speeds greater than the maximum supported one.
Also report nothing instead of "ok".
Inspired by patches by Bjorn Helgaas and Matthew Wilcox.
|
|
Users of the repeatedly complain that the library crashes, which is
usually caused by providing an error hook which returns to the library.
Let's try warning them more explicitly.
|
|
|
|
Update the tests files with the new field 10BitTagReq
in SR-IOV Capabilities Register.
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
|
|
Decode VF 10-Bit Tag Requester Supported and Enable bit
in SR-IOV Capabilities Register.
Sample output:
IOVCap: Migration- 10BitTagReq- Interrupt Message Number: 000
IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy- 10BitTagReq-
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
|
|
|
|
I believe "cc" is a much better default nowadays.
Another approach would be to (also) use "?=" for these variables.
|
|
i386-ports.c: In function ‘conf12_setup_io’:
i386-io-windows.h:1021: warning: ‘old_token’ may be used uninitialized in this function
i386-io-windows.h:1021: note: ‘old_token’ was declared here
It is always properly initialized when accessed, just gcc compiler does not see it.
|
|
It is used as argument for intel_cleanup_io() function.
|
|
UCRT, MSVCRT and CRTDLL runtime libraries provides only _strcmpi()
function and not strcmpi().
MinGW32 has static libraries libcoldname.a and libmoldname.a which provides
strcmpi() function (as link-time redirect to _strcmpi()). libcoldname.a is
automatically linked when compiling for CRTDLL runtime and libmoldname.a
for MSVCRT runtime.
MinGW-w64 has only libmoldname.a library with strcmpi() function and it is
linked to final executable only when compiling for MSVCRT runtime.
when linking with MSVCRT.
To prevent dependency on particular linking configuration and MinGW
toolchain, use set strcasecmp() as alias to _strcmpi() function which is
provided by any runtime library.
|
|
Remove "#if defined(__GNU_LIBRARY__)" guard for getopt() function
prototype in compat/getopt.h header file. The only purpose of
compat/getopt.h header is to provide getopt() function prototype for
compatibility purpose on every platform, specially those which do not use
GNU C library (e.g. Windows).
Without this change i586-mingw32msvc-gcc compiler complains that function
getopt() is used without defined prototype.
Also remove inclusion of #include <string.h> header file in compat/getopt.c
source file. Probably due to compatibility purposes compat/getopt.c file
has defined custom prototype for function strncmp() incompatible with C99
(length argument in C99 should be of type size_t). Including C99 prototype
of strncmp() function from MinGW32 <string.h> header file cause compile
errors for i586-mingw32msvc-gcc compiler. Instead of including <stringh>
provides custom and simple my_strncmp() implementation.
Thsi change fixes compilation of compat/getopt.c with i586-mingw32msvc-gcc,
i686-w64-mingw32-gcc, x86_64-w64-mingw32-gcc and also MSVC cl compilers.
|
|
MinGW32 since version 3.0 declares getopt() function prototype in
<unistd.h> header file.
|
|
As of PCIe 3.0, the LnkCtl2 "Compliance De-emphasis" field has been
renamed to "Compliance Preset/De-emphasis", and there are several new
bit encodings for various de-emphasis and preshoot combinations.
The name of the PCI_EXP_LNKCTL2_COM_DEEMPHASIS() macro is not changed
by this commit, as it is part of the libpci API.
Reported-by: Tim CC Chen(陳志佳) <Tim.CC.Chen@wnc.com.tw>
Signed-off-by: Lennert Buytenhek <buytenh@arista.com>
|
|
|
|
|
|
|
|
|
|
|
|
PCI Express Base Specification rev. 3.0 has the following definition for
the Slot Power Limit Value:
=======================================================================
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 = 250 W Slot Power Limit
F1h = 275 W Slot Power Limit
F2h = 300 W Slot Power Limit
F3h to FFh = Reserved for Slot Power Limit values above 300 W
=======================================================================
Replace function power_limit() by show_power_limit() which also prints
power limit value. Show reserved value as string ">300W".
|
|
Function intel_sanity_check() calls conf1_read() which access d->domain
field. But intel_sanity_check() does not initialize this field and so
conf1_read() access some random data on stack.
Tests showed that intel_sanity_check() always fails as in d->domain is
stored some non-zero number.
Fix this issue by zeroing struct pci_dev d in intel_sanity_check() as
sanity check is verifying PCI devices at domain 0.
|
|
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 value was quite misleading, as witnessed by multiple implementations
doing it wrong. In fact, the only return value which ever made sense was -1.
|
|
U-Boot's "pci display.b" command prints pci config space dump with 8 digits
in line number. So allow up to the 8 digits in line number to easily parse
U-Boot's pci config space dumps.
|
|
|
|
These files are old and cannot be used for compiling pcitutils anymore
(e.g. they use non-existent option TOOLPREFIX). As configure script now
works fine also for Windows build, remove these old win32 config files.
|
|
This change adds support for using configure script for cross-compiling
pciutils on Linux for Windows platforms.
Following command can be used to compile pcitils for Windows platform:
make CROSS_COMPILE=i586-mingw32msvc- HOST=i386-windows ZLIB=no IDSDIR=.
PCI_OS_WINDOWS does not support BSD DNS functions, so do not automatically
enable DNS support.
Library ioperm is cygwin specific and is used only for PCI_OS_CYGWIN.
|
|
This new option controls if compat/getopt.c should be compiled and linked
into lspci and setpci binaries. Useful for ancient platforms.
For example it is required to set COMPAT_GETOPT=yes for all versions of
MinGW32 with CRTDLL (as this MinGW32 variant does not have linkable
getopt() implementation). And also for MinGW32 with MSVCRT older than 3.0.
|
|
If x86_64-w64-mingw32-gcc compiler is called with -o filename option
without any file extension then compiler automatically appends suffix
".exe" to output filename.
This behavior of x86_64-w64-mingw32-gcc compiler basically breaks pattern
rule of type '%: %.o' as x86_64-w64-mingw32-gcc compiler cannot generate
arbitrary output file via -o option just by stripping .o extension from
filename.
When generating executables by x86_64-w64-mingw32-gcc compiler it is
really the best option to specify .exe suffix in -o option.
So introduce a new makefile variable EXEEXT which will be automatically
appended to any executable filename. For Windows and DOS systems set it
to ".exe". For other systems set it just to empty string "".
GNU automake uses same makefile variable for same purpose.
|
|
|
|
For Windows applications it is common to have all support data files in the
same directory where is stored executable itself, instead of in directory
hardcoded at compile time.
When PCI_PATH_IDS_DIR is set to "." it means that pci.ids file is located
in the current working directory. This is also unsuitable for Windows
command line applications stored in %PATH% because cmd.exe starts in some
default user or system location.
Adds a new option to allow specifying PCI_PATH_IDS_DIR to empty string ""
and for PCI_OS_WINDOWS platform it would mean to locate pci.ids file in the
same directory where is stored currently running executable. On Windows it
is always possible to detected this directory.
|
|
ProcessUserModeIOPL syscall
libpci uses WinIo library from http://www.internals.com/ which is archived
at https://web.archive.org/web/20151005172744/http://www.internals.com/
This external WinIo library has two big issues:
1. Library license is incompatible with pciutils license.
2. It silently and automatically installs 3rd-party NT kernel module
WinIo.sys which is bundled in WinIO.dll binary.
That NT kernel module creates a device file "\\.\WinIo" which can be opened
by any running process. Via this device file can any process (including
unprivileged or those running under Guest account) ask that kernel module
to configure x86 TSS I/O port permissions for access to any I/O port. That
NT kernel module does not implement any permission checks and automatically
accept all requests.
Change in this commit replaces insecure WinIO.dll library and WinIo.sys
kernel module by proper NT system solution: Usage of ProcessUserModeIOPL
syscall (equivalent of iopl(3) on Linux) which is supported directly by NT
kernel. It does not require any external 3rd-party library or NT kernel
module.
This syscall can be invoked by NtSetInformationProcess() function from
ntdll.dll library (which is part of NT system) and for privileged processes
kernel changes x86 IOPL to 3.
Privileged process is that which has SeTcbPrivilege (Act as part of the
operating system privilege) or is running under account from local
Administrators group with SeImpersonatePrivilege (Impersonate a client
after authentication privilege). SeImpersonatePrivilege is enabled by
default for accounts from local Administrators group.
Usage of privileges is not easy operation and needs to call lot of
functions to gain required permissions, achieve thread-safety and follow
suggested guidelines. Hence code is quite long.
Privileges (including SeTcbPrivilege) can be enabled / disabled in User
Accounts settings by local Administrators and change takes effect after
next login, not immediately.
|
|
CRTDLL and for 64-bit mode
Functions _outp(), _outpw(), _outpd(), _inp(), _inpw() and _inpd() are
available only in 32-bit version of the old MSVCRT library. They are not
available in 64-bit version of old MSVCRT library and neither the oldest
CRTDLL library or in new UCRT library.
Function prototypes for 32-bit mode should be available in <conio.h> header
file. But they are missing in some MinGW toolchains.
For 64-bit mode I/O port functions are defined only as inline functions or
intrinsics macros in <intrin.h> header file but under different names:
__outbyte(), __outword(), __outdword(), __inbyte(), __inword(), __indword()
This header file is available also in UCRT-compatible compilers.
When compiling with the oldest CRTDLL library and not using <intrin.h>
header file, it is required to provide own implementation of these
functions. Do it via inline assembly.
With this change it is possible to compile i386-io-windows.h with all
combination of toolchains, compilers, crt library and arch mode.
The most important is the fix to allow compilation with modern UCRT
library.
|
|
16/32-bit non-NT systems allow applications to access PCI I/O ports without
any special setup.
|
|
|
|
|
|
Include both the path and filename of pci.ids in the pci.ids man page
and the update-pciids man page
|
|
Add cross-references to gzip, bzip2, curl, wget, and lynx.
|
|
In the update-pciids man page:
* remove reference to setpci, since that does not use pci.ids
* add reference to pci.ids
Fixes: ef5b622f488e ("Added a man page for pci.ids")
|
|
|
|
|
|
|
|
Based on a patch by <lixiaokeng@huawei.com>.
|
|
There were multiple cases, in which malloc failure was either unchecked,
or a->error was called even though it was NULL.
|
|
This enables "lspci" to show PCIe 6.0 data rate (64 GT/s) properly
according to the contents in register PCI_EXP_LNKCAP, PCI_EXP_LNKSTA
and PCI_EXP_LNKCTL2.
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
guaranteed to set errnum so we initialized it to 0.
|
|
Allow five nibbles as valid domain, when reading from a dump file with
domain
|
|
If we move the file while making a backup, we can end up with no
pci.ids database in case the next step fails.
|
|
Fix code alignment by using a hard-tab instead of 4 spaces. Add a blank
line after set -e.
|
|
We should set -e as the first thing to catch any errors, so move the
quiet setup after the other variables setup.
|
|
Signed-off-by: Guillem Jover <guillem@hadrons.org>
|
|
The libpci.pc file does not seem to be correct for static linking.
$ pkg-config --libs --static libpci
-lpci
It brings no dependencies while -lresolv (and likely -lz) seems needed:
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/
libpci.a(names-net.o):function pci_id_net_lookup:
error: undefined reference to '__res_query'
Something like:
Libs.private: -lresolv -lz
Signed-off-by: Guillem Jover <guillem@hadrons.org>
|
|
This handles the case when the HOST has not been specified by the user.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
|
|
We need to set a sys variable matching what would be found in the GNU
triplet for the GNU/kFreeBSD architecture, otherwise the later code will
not match correctly.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
|
|
Decode 10-Bit Tag Requester Enable bit in Device Control 2 Register.
Sample output changes:
- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd-
+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled, ARIFwd-
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
|
|
Adjust PCI_EXP_DEV2_* to PCI_EXP_DEVCTL2_* macro definition to keep the
same style between the Linux kernel source [1] and lspci.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/pci_regs.h#n651
Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
|
|
Root Complex Event Collectors provide support for terminating error
and PME messages from RCiEPs. This patch provides basic decoding for
the lspci RCEC Endpoint Association Extended Capability. See PCIe 5.0-1,
sec 7.9.10 for further details.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
|
|
Hurd: bug fixes and compile again
|
|
|
|
Let us keep the bus scan light-weight. Whoever is interested
in device IDs, still has to call pci_fill_info(PCI_FILL_IDENT),
which handles this in generic way.
|
|
|
|
|
|
|
|
|
|
Fixes a bug introduced by commit 82c06b47dea5a38075ce9d56f743360bc47b4c78.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update the cap-dvsec-cxl test to match the new vendor ID.
Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
|
|
|
|
|
|
Adjusted the output to better match the rest of lspci.
Made the code more straightforward.
|
|
A patch by Paul Blinzer.
|
|
Even if the back-end does not implement multiple domains, it can
be called on a device in a non-zero domain if the use obtained the
device by calling pci_get_dev() instead of scanning the bus.
In all such cases, report that 0 bytes were read/written.
|
|
There was a lot of minor issues in the implementation of the fill_info
call-back in various back-ends. Most importantly, semantics of pci_dev->
known_fields was not formally defined and it was implemented inconsistently.
We now define known_fields as the set of fields which were already
obtained during the lifetime of the pci_dev. We never consider known
fields which are not supported by the back-end. All fields which are
unsupported by either the back-end, the OS, or the particular device,
are guaranteed to have sensible default values (0 or NULL). Also, bit
masks are always unsigned except for the signature of pci_fill_info()
which should be preferably kept stable.
All back-ends and the pci_generic_fill_info() function have been changed
to follow this semantics.
In the sysfs back-end, we read as few attributes as possible during
device initialization, so applications which use pci_get_dev() are not
slowed down unnecessarily.
In the Hurd back-end, we also respect the buscentric mode.
|
|
Reported by Sean V Kelley <sean.v.kelley@linux.intel.com> on the
linux-pci list.
|
|
We decode the DVSEC capability header first. If we recognize the vendor
and ID (and the length is at least the minimum we need), we call
a specific function to interpret the rest of the capability.
|
|
|
|
|
|
Compute eXpress Link[1] is a new CPU interconnect created with
workload accelerators in mind. The interconnect relies on PCIe
electrical and physical interconnect for communication via a Flex Bus
port which allows designs to choose between providing PCIe or CXL.
This patch introduces basic support for lspci decode of CXL and
builds upon the existing Designated Vendor-Specific support in
lspci through identification of a supporting CXL device using DVSEC
Vendor ID and DVSEC ID.
[1] https://www.computeexpresslink.org/
Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
|
|
Instead of current generic 'unknown' output for DVSEC, decode details on
Vendor ID, Rev, etc.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
|
|
General practice has been to use a comma after a multi-word item, but omit
commas between single-bit flags. Do this more consistently.
Sample output changes:
- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, NROPrPrP-, LTR+
+ DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR+
- 10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt-, EETLPPrefix-
+ 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
- FRS-, ARIFwd-
+ FRS- ARIFwd-
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Decode Link Capabilities 2, which includes the Supported Link Speeds
Vector, and decode more fields of Link Status 2.
The test case (data from https://bugzilla.kernel.org/show_bug.cgi?id=206837
comment #21) includes a Thunderbolt Downstream Port that advertises
2.5-8GT/s support in Link Capabilities 2.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
|
|
|
|
Allow clients to read and write from a device w/o a bus scan
|
