talos-op-linux/arch/microblaze/pci, branch v4.4.4

PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code"

2015-09-15T18:18:04+00:00

Revert dff22d2054b5 ("PCI: Call pci_read_bridge_bases() from core instead of arch code"). Reading PCI bridge windows is not arch-specific in itself, but there is PCI core code that doesn't work correctly if we read them too early. For example, Hannes found this case on an ARM Freescale i.mx6 board: pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff] pci 0000:00:00.0: PCI bridge to [bus 01-ff] pci 0000:00:00.0: BAR 8: no space for [mem size 0x01000000] (mem window) pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00200000] pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x00004000] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00000100] The 00:00.0 mem window needs to be at least 3MB: the 01:00.0 device needs 0x204100 of space, and mem windows are megabyte-aligned. Bus sizing can increase a bridge window size, but never *decrease* it (see d65245c3297a ("PCI: don't shrink bridge resources")). Prior to dff22d2054b5, ARM didn't read bridge windows at all, so the "original size" was zero, and we assigned a 3MB window. After dff22d2054b5, we read the bridge windows before sizing the bus. The firmware programmed a 16MB window (size 0x01000000) in 00:00.0, and since we never decrease the size, we kept 16MB even though we only needed 3MB. But 16MB doesn't fit in the host bridge aperture, so we failed to assign space for the window and the downstream devices. I think this is a defect in the PCI core: we shouldn't rely on the firmware to assign sensible windows. Ray reported a similar problem, also on ARM, with Broadcom iProc. Issues like this are too hard to fix right now, so revert dff22d2054b5. Reported-by: Hannes Reported-by: Ray Jui Link: http://lkml.kernel.org/r/CAAa04yFQEUJm7Jj1qMT57-LG7ZGtnhNDBe=PpSRa70Mj+XhW-A@mail.gmail.com Link: http://lkml.kernel.org/r/55F75BB8.4070405@broadcom.com Signed-off-by: Bjorn Helgaas Acked-by: Yinghai Lu Acked-by: Lorenzo Pieralisi

PCI: Call pci_read_bridge_bases() from core instead of arch code

2015-07-23T15:13:29+00:00

When we scan a PCI bus, we read PCI-PCI bridge window registers with pci_read_bridge_bases() so we can validate the resource hierarchy. Most architectures call pci_read_bridge_bases() from pcibios_fixup_bus(), but PCI-PCI bridges are not arch-specific, so this doesn't need to be in arch-specific code. Call pci_read_bridge_bases() directly from the PCI core instead of from arch code. For alpha and mips, we now call pci_read_bridge_bases() always; previously we only called it if PCI_PROBE_ONLY was set. [bhelgaas: changelog] Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas CC: Ralf Baechle CC: James E.J. Bottomley CC: Michael Ellerman CC: Bjorn Helgaas CC: Richard Henderson CC: Benjamin Herrenschmidt CC: David Howells CC: Russell King CC: Tony Luck CC: David S. Miller CC: Ingo Molnar CC: Guenter Roeck CC: Michal Simek CC: Chris Zankel

PCI: Assign resources before drivers claim devices (pci_scan_root_bus())

2015-03-19T15:17:13+00:00

Previously, pci_scan_root_bus() created a root PCI bus, enumerated the devices on it, and called pci_bus_add_devices(), which made the devices available for drivers to claim them. Most callers assigned resources to devices after pci_scan_root_bus() returns, which may be after drivers have claimed the devices. This is incorrect; the PCI core should not change device resources while a driver is managing the device. Remove pci_bus_add_devices() from pci_scan_root_bus() and do it after any resource assignment in the callers. Note that ARM's pci_common_init_dev() already called pci_bus_add_devices() after pci_scan_root_bus(), so we only need to remove the first call: pci_common_init_dev pcibios_init_hw pci_scan_root_bus pci_bus_add_devices # first call pci_bus_assign_resources pci_bus_add_devices # second call [bhelgaas: changelog, drop "root_bus" var in alpha common_init_pci(), return failure earlier in mn10300, add "return" in x86 pcibios_scan_root(), return early if xtensa platform_pcibios_fixup() fails] Signed-off-by: Yijing Wang Signed-off-by: Bjorn Helgaas CC: Richard Henderson CC: Ivan Kokshaysky CC: Matt Turner CC: David Howells CC: Tony Luck CC: Michal Simek CC: Ralf Baechle CC: Koichi Yasutake CC: Sebastian Ott CC: "David S. Miller" CC: Chris Metcalf CC: Chris Zankel CC: Max Filippov CC: Thomas Gleixner

microblaze/PCI: Clip bridge windows to fit in upstream windows

2015-01-16T16:04:43+00:00

Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas CC: Michal Simek CC: Benjamin Herrenschmidt CC: Sebastian Ott

microblaze: Fix IO space breakage after of_pci_range_to_resource() change

2014-10-27T07:29:54+00:00

Commit 0b0b0893d49b "of/pci: Fix the conversion of IO ranges into IO resources" changed the behaviour of of_pci_range_to_resource(). The issue is described here: "powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change" (sha1: aeba3731b150188685225b510886f1370d8814de) Signed-off-by: Michal Simek

Merge tag 'microblaze-3.16-rc1' of git://git.monstr.eu/linux-2.6-microblaze into next

2014-06-05T23:15:33+00:00

Pull Microblaze updates from Michal Simek: - cleanup PCI and DMA handling - use generic device.h - some cleanups * tag 'microblaze-3.16-rc1' of git://git.monstr.eu/linux-2.6-microblaze: microblaze: Fix typo in head.S s/substract/subtract/ microblaze: remove check for CONFIG_XILINX_CONSOLE microblaze: Use generic device.h microblaze: Do not setup empty unmap_sg function microblaze: Remove device_to_mask microblaze: Clean device dma_ops structure microblaze: Cleanup PCI_DRAM_OFFSET handling microblaze: Do not setup pci_dma_ops microblaze: Return default dma operations microblaze: Enable SERIAL_OF_PLATFORM

microblaze: Cleanup PCI_DRAM_OFFSET handling

2014-06-04T04:59:57+00:00

PCI_DRAM_OFFSET/pci_dram_offset is 0 all the time and there is no difference for PCI and !PCI cases. Also remove the whole code which setup archdata.dma_data which is completely unused. Signed-off-by: Michal Simek

microblaze: Do not setup pci_dma_ops

2014-06-04T04:59:56+00:00

pci_dma_ops are dma_direct_ops which are setup by default that's why not setup it again. Signed-off-by: Michal Simek

PCI: Move Open Firmware devspec attribute to PCI common code

2014-04-30T20:48:41+00:00

Move the devspec OF attribute to PCI common code's set of device attributes since it's not architecture dependent. As a side effect microblaze and powerpc no longer need to use pcibios_add_platform_entries(). [bhelgaas: fold in #include for compile error] Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrett Signed-off-by: Sebastian Ott Signed-off-by: Bjorn Helgaas Acked-by: Benjamin Herrenschmidt

microblaze/PCI: Use default pcibios_enable_device()

2014-03-19T21:00:14+00:00

We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Signed-off-by: Bjorn Helgaas CC: Michal Simek CC: microblaze-uclinux@itee.uq.edu.au