On Tuesday 19 February 2008 03:08:32 am Benjamin Herrenschmidt wrote: > On Tue, 2008-02-19 at 08:09 +0000, Russell King wrote: > > On Mon, Feb 18, 2008 at 09:39:52PM -0700, Bjorn Helgaas wrote: > > > > > > ARM and PA-RISC, in particular, have interesting differences: > > > - ARM always enables bridge devices, which no other arch does > > > > ARM does this because there is nothing else which would do that - which > > means devices behind bridges would be completely inaccessible. > > That's normally done by pci_enable_bridges() called by > pci_assign_unassigned_resources(). alpha, mips, mn10300, powerpc, and x86 use pci_enable_bridges() via pci_assign_unassigned_resources(). parisc uses pci_enable_bridges() directly from lba_driver_probe(). I guess the other arches (except arm) rely on firmware to enable bridge. I think pci_assign_unassigned_resources() is a bit of an anachronism -- it's a boot-time thing that does it for all root buses at once. A more hot-plug oriented scheme would do it like parisc, where every time we discover a root bridge, we do any necessary resource assignment and bridge enablement underneath it. For ARM, maybe that could happen in pcibios_init_hw() or something similar. > > > - PA-RISC always turns on SERR and PARITY, which no other arch does > > > > ARM also does this, unless pdev_bad_for_parity(dev) is true. See > > ARMs pcibios_fixup_bus(). > > While that sounds like a good idea to generalize, I think it should > remain arch stuff tho, not move to generic code. > > On some platforms, weirdo firmwares handle error handling and will be > unhappy if the kernel mucks around (such as pSeries). I agree the SERR and PARITY stuff probably needs to remain arch code. But it would be nice to at least have this and the bridge enable done in similar places across arches. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
