On 07/23/2015 09:12 AM, Bjorn Helgaas wrote:
On Thu, Jul 09, 2015 at 11:59:16AM +0100, Lorenzo Pieralisi wrote:
When a PCI bus is scanned, upon PCI bridge detection the kernel
has to read the bridge registers to set-up its resources so that
the PCI resource hierarchy can be validated properly.
Most if not all architectures read PCI bridge registers in the
pcibios_fixup_bus hook, that is called by the PCI generic layer
whenever a PCI bus is scanned.
Since pci_read_bridge_bases is an arch agnostic operation (and it
is carried out on all architectures) it can be moved to the generic
PCI layer in order to consolidate code and remove the respective
calls from the architectures back-ends.
The PCI_PROBE_ONLY flag is not checked before calling
pci_read_bridge_buses in the generic layer since reading the bridge
bases is not related to resources assignment; this implies that it
can be carried out safely on PCI_PROBE_ONLY systems too and should
not affect architectures (alpha, mips) that check the PCI_PROBE_ONLY
flag before reading the bridge bases.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
Applied to pci/resource for v4.3, thanks!
The PCI_PROBE_ONLY text seems backward to me: previously alpha and mips
only called pci_read_bridge_bases() if PCI_PROBE_ONLY was set. After this
patch, alpha and mips systems that do not set PCI_PROBE_ONLY will also call
pci_read_bridge_bases().
I really don't know why alpha and mips were like that. It seems backwards.
It seems like we'd want to know the bridge windows if we were assigning
things, but they only read them if they were *not* going to assign things.
I'm a little uneasy that we might break some alpha or mips system, since
there must have been some reason this was done originally. It'd be ideal
if somebody could test a non-PCI_PROBE_ONLY system. But maybe they're all
obsolete.
For alpha, PCI_PROBE_ONLY is set for two platforms, marvel and titan,
out of ~20. mips sets the flag for 6 platforms out of >25.
Unlikely that those are the only relevant ones.
I could try to run some qemu tests for both architectures, but I have
no idea what to look out for. Ideas, anyone ?
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
