[pciutils,0/4] Support for PCI_FILL_PARENT

Extend libpci API with a new option PCI_FILL_PARENT to fill parent
device for the current enumerated device. This can be useful in
situation when non-complaint PCI-to-PCI bridge-like device with Type 0
header is present in the system and behind this bridge are either
endpoint devices or another non-compliant bridges. This applies e.g.
for notoriously broken Galileo and Marvell PCI and PCIe devices.
lspci can will use PCI_FILL_PARENT information from the system if
config space does not provide enough information to build topology.

Pali Rohár (4):
  libpci: Add new option PCI_FILL_PARENT
  libpci: sysfs: Implement support for PCI_FILL_PARENT
  lspci: Build tree based on PCI_FILL_PARENT information
  lspci: Do not show -[00]- bus in tree output

 lib/pci.h   |  2 ++
 lib/sysfs.c | 31 ++++++++++++++++++++++++
 ls-tree.c   | 69 +++++++++++++++++++++++++++++++++++++++++++++++++----
 lspci.c     |  2 +-
 4 files changed, 98 insertions(+), 6 deletions(-)

Hello!

> Extend libpci API with a new option PCI_FILL_PARENT to fill parent
> device for the current enumerated device. This can be useful in
> situation when non-complaint PCI-to-PCI bridge-like device with Type 0
> header is present in the system and behind this bridge are either
> endpoint devices or another non-compliant bridges. This applies e.g.
> for notoriously broken Galileo and Marvell PCI and PCIe devices.
> lspci can will use PCI_FILL_PARENT information from the system if
> config space does not provide enough information to build topology.

Looks reasonable, but please put a better explanation in pci.h
(in particular, mention that this is not guaranteed to be available).

When reading the implementation in the sysfs backend, I wonder how you
can guarantee that at the moment of parsing the child device, the parent
device is already known to libpci.

				Martin

On Friday 21 January 2022 15:51:34 Martin Mareš wrote:
> Hello!
> 
> > Extend libpci API with a new option PCI_FILL_PARENT to fill parent
> > device for the current enumerated device. This can be useful in
> > situation when non-complaint PCI-to-PCI bridge-like device with Type 0
> > header is present in the system and behind this bridge are either
> > endpoint devices or another non-compliant bridges. This applies e.g.
> > for notoriously broken Galileo and Marvell PCI and PCIe devices.
> > lspci can will use PCI_FILL_PARENT information from the system if
> > config space does not provide enough information to build topology.
> 
> Looks reasonable, but please put a better explanation in pci.h
> (in particular, mention that this is not guaranteed to be available).

Ok!

> When reading the implementation in the sysfs backend, I wonder how you
> can guarantee that at the moment of parsing the child device, the parent
> device is already known to libpci.

All devices are parsed in sysfs_scan() function. And additional
information, including this "parent" is filled in sysfs_fill_info()
function. sysfs_scan() itself does not call sysfs_fill_info().

So prior calling pci_fill_info() it is required to call pci_scan_bus()
to have ->parent member filled.

> All devices are parsed in sysfs_scan() function. And additional
> information, including this "parent" is filled in sysfs_fill_info()
> function. sysfs_scan() itself does not call sysfs_fill_info().
> 
> So prior calling pci_fill_info() it is required to call pci_scan_bus()
> to have ->parent member filled.

Ah, OK. My fault.

It's OK then.

			Have a nice fortnight