1. 16 9月, 2015 1 次提交
    • B
      PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code" · 237865f1
      Bjorn Helgaas 提交于
      Revert dff22d20 ("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
      d65245c3 ("PCI: don't shrink bridge resources")).  Prior to
      dff22d20, ARM didn't read bridge windows at all, so the "original size"
      was zero, and we assigned a 3MB window.
      
      After dff22d20, 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 dff22d20.
      Reported-by: NHannes <oe5hpm@gmail.com>
      Reported-by: NRay Jui <rjui@broadcom.com>
      Link: http://lkml.kernel.org/r/CAAa04yFQEUJm7Jj1qMT57-LG7ZGtnhNDBe=PpSRa70Mj+XhW-A@mail.gmail.com
      Link: http://lkml.kernel.org/r/55F75BB8.4070405@broadcom.comSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      237865f1
  2. 23 7月, 2015 1 次提交
    • L
      PCI: Call pci_read_bridge_bases() from core instead of arch code · dff22d20
      Lorenzo Pieralisi 提交于
      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: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Ralf Baechle <ralf@linux-mips.org>
      CC: James E.J. Bottomley <jejb@parisc-linux.org>
      CC: Michael Ellerman <mpe@ellerman.id.au>
      CC: Bjorn Helgaas <bhelgaas@google.com>
      CC: Richard Henderson <rth@twiddle.net>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: David Howells <dhowells@redhat.com>
      CC: Russell King <linux@arm.linux.org.uk>
      CC: Tony Luck <tony.luck@intel.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: Guenter Roeck <linux@roeck-us.net>
      CC: Michal Simek <monstr@monstr.eu>
      CC: Chris Zankel <chris@zankel.net>
      dff22d20
  3. 19 3月, 2015 1 次提交
    • Y
      PCI: Assign resources before drivers claim devices (pci_scan_root_bus()) · b97ea289
      Yijing Wang 提交于
      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: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Richard Henderson <rth@twiddle.net>
      CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      CC: Matt Turner <mattst88@gmail.com>
      CC: David Howells <dhowells@redhat.com>
      CC: Tony Luck <tony.luck@intel.com>
      CC: Michal Simek <monstr@monstr.eu>
      CC: Ralf Baechle <ralf@linux-mips.org>
      CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      CC: Sebastian Ott <sebott@linux.vnet.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Chris Metcalf <cmetcalf@ezchip.com>
      CC: Chris Zankel <chris@zankel.net>
      CC: Max Filippov <jcmvbkbc@gmail.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      b97ea289
  4. 06 6月, 2013 1 次提交
  5. 04 10月, 2012 1 次提交
  6. 19 9月, 2012 2 次提交
  7. 06 7月, 2012 1 次提交
  8. 14 6月, 2012 1 次提交
  9. 24 2月, 2012 1 次提交
  10. 07 1月, 2012 2 次提交
    • B
      xtensa/PCI: convert to pci_scan_root_bus() for correct root bus resources · 7ec303a7
      Bjorn Helgaas 提交于
      Convert from pci_scan_bus() to pci_scan_root_bus() and remove root bus
      fixups.  This fixes the problem of "early" and "header" quirks
      seeing incorrect root bus resources.
      
      This arch was unusual because it filled in bus->resource[0..3] in
      pcibios_init(), then overwrote them, applied io_space.offset and
      checked for unset resources in pcibios_fixup_bus().  I moved all of
      that to a new pci_controller_apertures() that we can use before
      scanning the root bus.
      
      CC: Chris Zankel <chris@zankel.net>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      7ec303a7
    • M
      PCI: Xtensa: convert pcibios_set_master() to a non-inlined function · 9cdce18d
      Myron Stowe 提交于
      This patch converts Xtensa's architecture-specific
      'pcibios_set_master()' routine to a non-inlined function.  This will
      allow follow on patches to create a generic 'pcibios_set_master()'
      function using the '__weak' attribute which can be used by all
      architectures as a default which, if necessary, can then be over-
      ridden by architecture-specific code.
      
      Converting 'pci_bios_set_master()' to a non-inlined function will
      allow Xtensa's 'pcibios_set_master()' implementation to remain
      architecture-specific after the generic version is introduced and
      thus, not change current behavior.
      
      No functional change.
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9cdce18d
  11. 23 2月, 2010 2 次提交
  12. 28 8月, 2007 1 次提交
  13. 01 6月, 2007 1 次提交
  14. 04 10月, 2006 1 次提交
  15. 01 7月, 2006 1 次提交
  16. 28 6月, 2006 1 次提交
  17. 26 6月, 2006 1 次提交
  18. 23 9月, 2005 1 次提交
  19. 30 6月, 2005 1 次提交
  20. 24 6月, 2005 1 次提交