On Wed, Jan 30, 2013 at 3:28 PM, Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote: > Dear Bjorn Helgaas, > > On Wed, 30 Jan 2013 11:52:15 -0700, Bjorn Helgaas wrote: >> It looks like your current system doesn't support trees below the >> bridges, but hopefully we can make it so the generic enumeration >> algorithms still work. > > In practice, in our situation, there isn't a tree below the bridge. > There is one single device. I'd prefer to not implement features that I > cannot effectively test, and let the implementation of those additional > features to whoever will need them, and therefore be able to test them. I understand the concern about testing, but my advice is to not use that as an excuse to artificially limit the functionality of the code you're writing :) You're talking about emulating a bridge, and the bridge really doesn't know or care what's downstream. If it works with a single device downstream, it should work with another bridge downstream. Many aspects of bridge configuration can be tested with creative application of setpci, so that might be a possibility, too. > I guess that if I integrate the PCI-to-PCI bridge emulation code within > the Marvell driver, then I can keep it fairly limited to whatever the > Marvell PCI driver requires, no? Yeah, it's just that the pci_dev for this emulated bridge is used by the generic PCI core code, e.g., pci_scan_bridge(), so whatever emulation you do has to be robust enough that the core won't notice it's emulated. Bjorn -- 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
