Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44917 )
Change subject: soc/intel/tigerlake: Enable and use USB4 PCIe driver ......................................................................
Patch Set 16:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44917/3/src/soc/intel/tigerlake/chi... File src/soc/intel/tigerlake/chipset.cb:
https://review.coreboot.org/c/coreboot/+/44917/3/src/soc/intel/tigerlake/chi... PS3, Line 8: chip drivers/intel/usb4/pcie : register "port_id" = "0" : use tbt_dma0 as usb4_port : device pci 07.0 alias tbt_pcie_rp0 off end : end Aah I see now what you were saying.
1. child GENERIC: 0.0 not a PCI device (repeated a couple dozen times)
This is because `pci_scan_get_dev()` expects the children of the bridge to be only PCI devices. If it doesn't find that, it prints this out as it is looking for existing device structure among the children of the bridge.
2. PCI: Leftover static devices: GENERIC: 0.0
This is because `do_pci_scan_bridge()` only calls `do_scan_bus()` for actual PCI devices using min and max devfn. It never really scans the generic device and so ends up removing it as unused static device.
In the end for volteer it doesn't matter too much if the pci bridges behind a TBT device actually get scanned and set up since we don't want external PCI enumerated in the firmware anyway, we just need the ACPI tables and leave the rest to the OS for now.
That's true. I think the question would be how do we want to treat dummy/virtual devices added under PCIe bridges like USB4 or NVMe. Do we want those devices to be simply PCI devices and use that as proxy to add SSDT information under the parent? Or do we want to enable coreboot infrastructure to allow scanning for non-PCI virtual devices under the bridge?