On Tue, 2009-05-19 at 09:28 -0600, Grant Likely wrote: > 1) Probe the host controller in an of_platform driver. This has the > advantage of simplicity. The probe routine will get automatically > called when the PCI host controller device tree node is registered > with the of_platform bus. The bus parenthood also gets reflected in > the device model and sysfs. The disadvantage is that it defers PCI > bus probing until after the of_platform bus is probed (maybe this is > okay; maybe this already happens anyway).
We are doing that on Cell as mentioned by Arnd. However, there are a few issues with that approach. One is that it relies on PCI-hotplug related bits that currently only exist in 64-bit land. Another is that doing so tends to expose various hidden issues or subtle dependencies to the PCI stuff being setup early and probed early. For example, some of the OF parsing bits may fail to convert memory addresses to IO addresses if the PCI host bridges have not been discovered yet, potentially causing issues with matching of resources between the early serial stuff and the generic serial driver (if you use an IO driven UART, the PCI 8250 driver may not properly figure out that what it's finding in its IO BARs is actually the same port as what it gets from the platform code as the later will end up with memory addresses rather than IO ones). That's one example. At this stage, I much prefer if we stick to doing the PHB discovery at setup_arch() time, especially since there's other WIP in the area of PCI coming from Kumar and I don't want to mixup multiple source of problems in that area at the same time. We can revisit that later but we'll have to be very careful. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
