> From: Ard Biesheuvel [mailto:[email protected]] > Sent: 30 May 2017 11:14 > To: Scott Telford <[email protected]> > Cc: Leif Lindholm <[email protected]>; [email protected] <edk2- > [email protected]>; Tian, Feng <[email protected]>; Zeng, Star > <[email protected]> > Subject: Re: [edk2] [PATCH] Copy bus scanning workaround from ARM Juno > PCIe driver.
> >> I'd still like to understand why this issue does not occur under > >> Linux, or if it does occur, if we need an ECAM quirk for Juno to work > >> around it. Reading up on the subject, in the PCI Express Base Specification 3.0, section 7.3.1 (Configuration Transaction Rules: Device Number) states "Non-ARI [Alternative Routing-ID Interpretation] Devices must respond to all Type 0 Configuration Read Requests, regardless of the Device Number specified in the Request", which I guess would explain what I'm seeing with the same device appearing at all possible device numbers when reading the VIDs, without the workaround present. In Linux's drivers/pci/probe.c, the functions pci_scan_slot() and only_one_child() will scan only device 0 function 0 if the parent bus is a PCIe root port or downstream port. See the comment for commit f07852d6442c46c50b59c7e2acc8a1b291f9ab6d: "We can then speed up the pci_scan_slot by skipping the scan of subsequent devfns for PCIe devices which are the direct children of Root Ports or Downstream Ports. These devices are only permitted to implement device 0, unless they are ARI devices, in which case they'll be scanned by the ARI code above." So it doesn't matter if they respond to all device numbers, because we know they're only allowed to have a device 0. However, PciLib.c:PciScanBus() in TianoCore will always scan for all possible devices. Looks like it should be behaving more like the Linux driver in the case of PCIe? Regards, Scott. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
