1. 24 6月, 2016 1 次提交
  2. 21 6月, 2016 2 次提交
  3. 15 10月, 2015 1 次提交
  4. 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
  5. 06 8月, 2015 1 次提交
  6. 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
  7. 03 6月, 2015 2 次提交
  8. 11 4月, 2015 8 次提交
  9. 10 4月, 2015 1 次提交
    • M
      powerpc: Replace mem_init_done with slab_is_available() · f691fa10
      Michael Ellerman 提交于
      We have a powerpc specific global called mem_init_done which is "set on
      boot once kmalloc can be called".
      
      But that's not *quite* true. We set it at the bottom of mem_init(), and
      rely on the fact that mm_init() calls kmem_cache_init() immediately
      after that, and nothing is running in parallel.
      
      So replace it with the generic and 100% correct slab_is_available().
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      f691fa10
  10. 31 3月, 2015 3 次提交
    • W
      powerpc/powernv: Implement pcibios_iov_resource_alignment() on powernv · 5350ab3f
      Wei Yang 提交于
      Implement pcibios_iov_resource_alignment() on powernv platform.
      
      On PowerNV platform, there are 3 cases for the IOV BAR:
      1. initial state, the IOV BAR size is multiple times of VF BAR size
      2. after expanded, the IOV BAR size is expanded to meet the M64 segment size
      3. sizing stage, the IOV BAR is truncated to 0
      
      pnv_pci_iov_resource_alignment() handle these three cases respectively.
      
      [bhelgaas: adjust to drop "align" parameter, return pci_iov_resource_size()
      if no ppc_md machdep_call version]
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5350ab3f
    • W
      powerpc/powernv: Reserve additional space for IOV BAR according to the number of total_pe · 6e628c7d
      Wei Yang 提交于
      On PHB3, PF IOV BAR will be covered by M64 BAR to have better PE isolation.
      M64 BAR is a type of hardware resource in PHB3, which could map a range of
      MMIO to PE numbers on powernv platform. And this range is divided equally
      by the number of total_pe with each divided range mapping to a PE number.
      Also, the M64 BAR must map a MMIO range with power-of-two size.
      
      The total_pe number is usually different from total_VFs, which can lead to
      a conflict between MMIO space and the PE number.
      
      For example, if total_VFs is 128 and total_pe is 256, the second half of
      M64 BAR will be part of other PCI device, which may already belong to other
      PEs.
      
      This patch prevents the conflict by reserving additional space for the PF
      IOV BAR, which is total_pe number of VF's BAR size.
      
      [bhelgaas: make dev_printk() output more consistent, index resource[]
      conventionally]
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6e628c7d
    • W
      powerpc/pci: Don't unset PCI resources for VFs · c3b80fb0
      Wei Yang 提交于
      Flag PCI_REASSIGN_ALL_RSRC is used to ignore resources information setup by
      firmware, so that kernel would re-assign all resources of pci devices.
      
      On powerpc arch, this happens in a header fixup function
      pcibios_fixup_resources(), which will clean up the resources if this flag
      is set. This works fine for PFs, since after clean up, kernel will
      re-assign the resources in pcibios_resource_survey().
      
      Below is a simple call flow on how it works:
      
          pcibios_init
            pcibios_scan_phb
              pci_scan_child_bus
                ...
                  pci_device_add
                    pci_fixup_device(pci_fixup_header)
                      pcibios_fixup_resources                     # header fixup
                        for (i = 0; i < DEVICE_COUNT_RESOURCE; i++)
                          dev->resource[i].start = 0
            pcibios_resource_survey                               # re-assign
              pcibios_allocate_resources
      
      However, the VF resources won't be re-assigned, since the VF resources are
      completely determined by the PF resources, and the PF resources have
      already been reassigned. This means we need to leave VF's resources
      un-cleared in pcibios_fixup_resources().
      
      In this patch, we skip the resource unset process in
      pcibios_fixup_resources(), if the pci_dev is a VF.
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c3b80fb0
  11. 17 1月, 2015 1 次提交
    • Y
      powerpc/PCI: Clip bridge windows to fit in upstream windows · 3ebfe46a
      Yinghai Lu 提交于
      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=85491Reported-by: NMarek Kordik <kordikmarek@gmail.com>
      Fixes: 5b285415 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: Paul Mackerras <paulus@samba.org>
      CC: Michael Ellerman <mpe@ellerman.id.au>
      CC: Gavin Shan <gwshan@linux.vnet.ibm.com>
      CC: Anton Blanchard <anton@samba.org>
      CC: Sebastian Ott <sebott@linux.vnet.ibm.com>
      CC: Wei Yang <weiyang@linux.vnet.ibm.com>
      CC: Andrew Murray <amurray@embedded-bits.co.uk>
      CC: linuxppc-dev@lists.ozlabs.org
      3ebfe46a
  12. 19 11月, 2014 1 次提交
    • M
      powerpc: Remove more traces of bootmem · e39f223f
      Michael Ellerman 提交于
      Although we are now selecting NO_BOOTMEM, we still have some traces of
      bootmem lying around. That is because even with NO_BOOTMEM there is
      still a shim that converts bootmem calls into memblock calls, but
      ultimately we want to remove all traces of bootmem.
      
      Most of the patch is conversions from alloc_bootmem() to
      memblock_virt_alloc(). In general a call such as:
      
        p = (struct foo *)alloc_bootmem(x);
      
      Becomes:
      
        p = memblock_virt_alloc(x, 0);
      
      We don't need the cast because memblock_virt_alloc() returns a void *.
      The alignment value of zero tells memblock to use the default alignment,
      which is SMP_CACHE_BYTES, the same value alloc_bootmem() uses.
      
      We remove a number of NULL checks on the result of
      memblock_virt_alloc(). That is because memblock_virt_alloc() will panic
      if it can't allocate, in exactly the same way as alloc_bootmem(), so the
      NULL checks are and always have been redundant.
      
      The memory returned by memblock_virt_alloc() is already zeroed, so we
      remove several memsets of the result of memblock_virt_alloc().
      
      Finally we convert a few uses of __alloc_bootmem(x, y, MAX_DMA_ADDRESS)
      to just plain memblock_virt_alloc(). We don't use memblock_alloc_base()
      because MAX_DMA_ADDRESS is ~0ul on powerpc, so limiting the allocation
      to that is pointless, 16XB ought to be enough for anyone.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      e39f223f
  13. 05 11月, 2014 1 次提交
  14. 16 10月, 2014 1 次提交
    • M
      powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change · aeba3731
      Michael Ellerman 提交于
      Commit 0b0b0893 "of/pci: Fix the conversion of IO ranges into IO
      resources" changed the behaviour of of_pci_range_to_resource().
      
      Previously it simply populated the resource based on the arguments. Now
      it calls pci_register_io_range() and pci_address_to_pio(). These both
      have two implementations depending on whether PCI_IOBASE is defined,
      which it is not for powerpc.
      
      Further complicating matters, both routines are weak, and powerpc
      implements it's own version of one - pci_address_to_pio(). However
      powerpc's implementation depends on other initialisations which are done
      later in boot.
      
      The end result is incorrectly initialised IO space. Often we can get
      away with that, because we don't make much use of IO space. However
      virtio requires it, so we see eg:
      
        pci_bus 0000:00: root bus resource [io  0xffff] (bus address [0xffffffffffffffff-0xffffffffffffffff])
        PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
        virtio-pci 0000:00:01.0: can't enable device: BAR 0 [io  size 0x0020] not assigned
      
      The simplest fix for now is to just stop using of_pci_range_to_resource(),
      and open-code the original implementation, that's all we want it to do.
      
      Fixes: 0b0b0893 ("of/pci: Fix the conversion of IO ranges into IO resources")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      aeba3731
  15. 03 10月, 2014 1 次提交
  16. 25 9月, 2014 1 次提交
  17. 04 7月, 2014 1 次提交
  18. 01 5月, 2014 1 次提交
  19. 28 4月, 2014 2 次提交
  20. 22 12月, 2013 1 次提交
    • Y
      PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev · fc279850
      Yinghai Lu 提交于
      These interfaces:
      
        pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
      
      took a pci_dev, but they really depend only on the pci_bus.  And we want to
      use them in resource allocation paths where we have the bus but not a
      device, so this patch converts them to take the pci_bus instead of the
      pci_dev:
      
        pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
      
      In fact, with standard PCI-PCI bridges, they only depend on the host
      bridge, because that's the only place address translation occurs, but
      we aren't going that far yet.
      
      [bhelgaas: changelog]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fc279850
  21. 24 10月, 2013 3 次提交
    • G
      of/irq: simplify args to irq_create_of_mapping · e6d30ab1
      Grant Likely 提交于
      All the callers of irq_create_of_mapping() pass the contents of a struct
      of_phandle_args structure to the function. Since all the callers already
      have an of_phandle_args pointer, why not pass it directly to
      irq_create_of_mapping()?
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      e6d30ab1
    • G
      of/irq: Replace of_irq with of_phandle_args · 530210c7
      Grant Likely 提交于
      struct of_irq and struct of_phandle_args are exactly the same structure.
      This patch makes the kernel use of_phandle_args everywhere. This in
      itself isn't a big deal, but it makes some follow-on patches simpler.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      530210c7
    • G
      of/irq: Rename of_irq_map_* functions to of_irq_parse_* · 0c02c800
      Grant Likely 提交于
      The OF irq handling code has been overloading the term 'map' to refer to
      both parsing the data in the device tree and mapping it to the internal
      linux irq system. This is probably because the device tree does have the
      concept of an 'interrupt-map' function for translating interrupt
      references from one node to another, but 'map' is still confusing when
      the primary purpose of some of the functions are to parse the DT data.
      
      This patch renames all the of_irq_map_* functions to of_irq_parse_*
      which makes it clear that there is a difference between the parsing
      phase and the mapping phase. Kernel code can make use of just the
      parsing or just the mapping support as needed by the subsystem.
      
      The patch was generated mechanically with a handful of sed commands.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      0c02c800
  22. 23 8月, 2013 1 次提交
  23. 14 8月, 2013 3 次提交
  24. 24 7月, 2013 1 次提交
    • G
      powerpc/pci: Partial tree hotplug support · ab444ec9
      Gavin Shan 提交于
      When EEH error happens to one specific PE, the device drivers
      of its attached EEH devices (PCI devices) are checked to see
      the further action: reset with complete hotplug, or reset without
      hotplug. However, that's not enough for those PCI devices whose
      drivers can't support EEH, or those PCI devices without driver.
      So we need do so-called "partial hotplug" on basis of PCI devices.
      In the situation, part of PCI devices of the specific PE are
      unplugged and plugged again after PE reset.
      
      The patch changes pcibios_add_pci_devices() so that it can support
      full hotplug and so-called "partial" hotplug based on device-tree
      or real hardware. It's notable that pci_of_scan.c has been changed
      for a bit in order to support the "partial" hotplug based on dev-tree.
      
      Most of the generic code already supports that, we just need to
      plumb it properly on our side.
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ab444ec9