On Monday, July 4, 2016 10:56:27 AM CEST Liviu Dudau wrote: > On Fri, Jul 01, 2016 at 06:30:24PM +0200, Arnd Bergmann wrote: > > On Friday, July 1, 2016 5:09:23 PM CEST Liviu Dudau wrote: > > > Don't get me wrong, clearly someone needs to create an instance of pci_host_bridge. > > > What I want people to accept is that in the PCI(e) architecture there is nothing that > > > stops a piece of HW that used to be the bridge between host and underlying bus into > > > becoming the bridge between a higher PCI(e) bus and the bus underneath. If the writes > > > to the configuration registers happens somehow, the Host Bridge doesn't even know if > > > it is talking to the actual host. Can the driver in that case make sure it did not made > > > assumptions that were tied to a specific SoC implementation? > > > > Sorry, I'm not really following what you mean with that, or what the > > consequence is for the Linux implementation. Can you try to rephrase this? > > I'm thinking drivers expecting to drive the bridge between the host and the PCI bus. > When that HW is used to bridge between another bus (PCI or PCIe) because the > functionality was there all the time in terms of signals, the driver's assumptions > break down. But maybe I'm being too theoretical and such beasts don't exist? (I remember > seeing a network card that had native PCI chip plus an added PCIe-to-PCI bridge and > the driver was tripping badly, but I can't remember the exact details. I think we should expect all non-host PCI bridges to behave according to the normal PCI spec and get handled by the PCI core. There are some handlers for broken bridges in drivers/pci/quirks.c, which is not nice but there is little alternative, and I don't think that hooking into the PCI host bridge driver code would help here. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
