Bjorn Helgaas <bhelgaas <at> google.com> writes: > > On Thu, Jan 9, 2014 at 3:51 AM, Sunil Kovvuri <sunil.kovvuri <at> gmail.com> wrote: > > Hi, > > > > I have a platform which has a on-board PCIe device attached to PCIe port. > > This device is an ethernet device with SRIOV capability having morethan > > 8 virtual functions. > > > > I am going through Linux's ARI configuration code and saw that it is checking > > if upstream bridge supports ARI or not. In our case its a on-board device and > > no bridge is involved. > > > > Need some help or ideas on how i can configure ARI on the device so that > > all VFs gets added. > > > > Do i need to change the ARI configuration code or is there a way to fake a > > PCI bridge for this purpose ? > > I assume you're referring to pci_configure_ari(). A PCIe endpoint > such as your ethernet device always has an upstream bridge. In your > case, the device is on-board and there's no PCIe switch involved, but > the root port is the upstream device, and it is handled as a bridge. > > It looks like pci_configure_ari() should enable ARI by default when it > is supported. But apparently it isn't being enabled on your system? > Can you collect the "lspci -vv" output for the root port and the NIC? > > Bjorn > Hi Bjorn, For the sake of discussion, let's assume that the device in question, which is intended to appear to software as a pci-express SR-IOV device with more than 8 functions (i.e. ARI), has a PCI-Express configuration space which is slotted into an ECAM region for discovery and configuration. The device itself is directly attached to the host-bridge and doesn't have an associated root port. In this case, the check for bridge in pci_configure_ari() is problematic because there is no root port (the host bridge is transparent to software). thanks, scott -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
