[RFC PATCH] PCI-E broken on PPC (regression)

Benjamin Herrenschmidt benh at kernel.crashing.org
Wed Jan 27 13:10:56 EST 2010


> Cc'ing Ben for PPC.  Ben, should PPC use pci_scan_device when probing
> its root busses?  Sounds like it just uses pci_device_add for each one
> it finds instead?
> 
> If you don't actually need scanning (though what about hotplug?) we can
> move the call to device_add instead...

Ok so I looked at the code and the problem goes way beyond root busses.

Basically, powerpc can use the code in arch/powerpc/kernel/pci_of_scan.c
to "generate" the pci_dev without using config space probing or at least
using as little of it as possible, using the firmware device-tree
information instead.

This is also probably going to be moved to a more generic place and
extended to be used optionally by other architectures.

I think sparc does something similar in fact in arch/sparc/kernel/pci.c
(of_create_pci_dev()) though it would be logical to have sparc and
powerpc share the same implementation here in the long run and I believe
Grant Likely is working on it.

That means that potentially, pci_dev will be created on those archs for
which pci_setup_device() is never called. Thus we need to be very
careful when adding initializations there that at least we (myself and
davem) are notified of that so we can mirror them in our code, or even
better, if people doing so put them there too...

So as far as I can tell, we are missing that set_pcie_port_type(), so we
need to add it to sparc and powerpc (and so make the function non-static
in drivers/pci/probe.c). We are also missing the manipulation of
dev->slot in fact, so that will need to be fixed too.

set_pcie_hotplug_bridge() might be something we want to add too, it's
not totally clear yet due to possible issues with our firmwares.
pci_fixup_device(pci_fixup_early,...) as well in fact.

I'll try do make ppc catch up with some of that see how it goes.

Cheers,
Ben.




More information about the Linuxppc-dev mailing list